> > As nice and well-done your framework is, it is still "yet another" approach to
> > provide strong typing to C++.
> But it is different from many previous approaches since it does not require
> defining constructors or own operators.

Indeed, it reminded me of https://www.fluentcpp.com/2017/05/23/strong-types-inheriting-functionalities-from-underlying/
Or https://foonathan.net/2016/10/strong-typedefs/

> > Suppose I have created my own, and I use a library providing its own, and I
> > use another library providing yours... Now I have at least 3 incompatible and
> > competing "strong typing" frameworks in my software.
>
> So what, that is always the case if different librarys share common non-
> standardized abstractions. With that argument, we would be using
> void* throughout any interface (in C++), fortunately we do not need that
> anymore.

That's precisely the point: if an abstraction is common, often requested and/or
talked about, and several implementations appears, then it looks like a candidate
for standardization.
Before boost::filesystem then std::filesystem how many implementations have
been created for the same abstractions?

> > Complexity, confusion... similar situation when you have to use geometric point
> > types and you have to use several libraries, each providing their own ones 😊
> > glm::vec3 and Eigen::Vector3f are basically the same thing yet it's a pain if I
> > have to combine them in a single algorithm, because using 3rd party libraries.
>
> Considering that specific example, what is the problem in those libraries is that
> the same type is used for the affine space and the vector space (with an origin)

Granted maybe it's not the best example. What I mean here is, when you have to
deal with several libraries each providing their own implementation for the *same*
abstraction with the same (or "almost" the same) semantic. Sometimes it's hardly
avoidable, sometimes maybe something can be done to reduce the proliferation.

> [...]
> I just say, we already have a type system supporting strong types (may be not
> as simple as in Ada, but that was not yet my goal).

And I did my best to *not* mention Ada ;-)

> > And strong typing is not only about distinguishing types but also limit the
> > available operations to those that make sense for the intended semantics, i.e.,
> > if you have a struct name:strong<std::string,name>{}; you would not expect a
> > name to support mutations, for example.

Totally agree.

> > Maybe, probably it can be done at the library level. However, a library
> > implementation involves some more or less heavy template machinery, making
> > it not so easy to use.
> Did you look at my attempt. I consider the user side not really template heavy.
> You can have a single template to inherit from with two obligatory arguments
> and may be some more for a select set of supported operations.

Yes, but the simpler the better.

> > Moreover it would probably increase compile time, which is usually not
> > desirable (I daily work on softwares that typically need hours to build).
> Did you compare that to a language feature? Why wouldn't that increase
> compile time?

Maybe it would, but hopefully less than having to instantiate 2000 templates
from 2000 source files - maybe 2000 times the same one.

> The biggest fear I have about introducing new language features is the
> unforseen interaction with the rest of the language. This could mean that those
> language-defined strong types behave differently from the existing types. We
> have such a wart already with enum types that are kind of second-class user-
> defined types.

Totally agree, that's why things shall be discussed.
 
> > Also a library implementation implies some kind of tag to distinguish
> > between the "strongly type types", either a value or an empty type.
> Again, you didn't seem to bother to look at my implementation. The type itself
> is the tag, so no need to manage that, since you need to give a name anyway.
> The only hurdle is that you have to repeat it once in its own definition, so there
> is the copy-waste issue, but that would easily result in a compile error.

True, I overlooked that.

> A language change was proposed before and failed to reach consensus
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0109r0.pdf

I know that, I even linked to it in my initial message.

Regards,