Also, now we support Conan 2.0, which provides an updated way of handling dependencies.
## What is gone?
Some cornerstones of the initial design did not prove in practice and were removed while
we moved to version 2.
### The downcasting facility
The first and the most important of such features was removing the downcasting facility.
This feature is still a powerful metaprogramming technique that allows users to map long class template
instantiations to nicely named, short, and easy-to-understand user's strong types.
Such mapping works perfectly fine for 1-to-1 relationships. However, we often deal with N-to-1 connections in the quantities and units domain. Here are only a few such examples:
- _work_ and _torque_ have the same dimension $L^2MT^{-2}$,
- becquerel and hertz have the same definition of $s^{-1}$,
- litre and cubic decimetre have the same factor.
In the above examples, multiple entities "wanted" to register different names for identical class
template instantiations, resulting in compile-time errors. We had to invent some hacks and
workarounds to make it work, but we were never satisfied with the outcome.
Additionally, this facility could easily lead to ODR violations or provide different results
depending on which header files were included in the translation units. This was too vulnerable
### No construction of a `quantity` from a raw value
To improve safety, we no longer allow the construction of quantities from raw values. In the new design, we
always need to explicitly specify a unit to create a `quantity`:
```cpp
quantity q1 = 42 * m;
quantity<si::metre> = 2 * km;
quantity q3(42, si::metre);
```
The previous approach was reported to be error-prone under maintenance. More on this subject
can be found in the
[Why can't I create a quantity by passing a number to a constructor?](../../getting_started/faq.md#why-cant-i-create-a-quantity-by-passing-a-number-to-a-constructor)
