So, let me get this straight:
* You don't want `cast(signed)`, because of the range
difference between the types.
* You want `cast(signed int)` but not as syntactic salt -
which means you still want `cast(int)` to work.
How about `cast(/*signed*/ int)`?
- I do want cast(signed)
- I don't want to suggest cast(int) should not work, but rather
to think of a solution for better documentation in the code, and
to encourage people to write:
cast(signed) // when they're casting unsigned->signed
cast(int) // when they're casting short->int
- I still feel slightly uneasy about the previous point. What I
mentioned about cast(signed int) was a form of brainstorming. I
wanted to try to give some consideration to people who'd want the
destination datatype to be explicit, as it says something about
the destination range. However, the fact that we must be careful
of the range is already implied by cast(signed) and
cast(unsigned).
- I like how cast(const) uses the lowercase const and the same
const keyword. There's a nice consistency about that. So I don't
want them in the library.
- Cast operations should be available without module imports.
- I would use the cast(signed) and feel comfortable.
- I could use the signed(x) and enjoy it! cast(signed) is not a
super important thing like the :=
- I think *your* idea was good and possibly better than mine, as
it allows library authors to create new numerical types that
support signed/unsigned casting, and yet still access it via
cast(signed) if 'signed' was the template.
- I'm not sure if Walter & Andrei would want
cast(ToWorkWithTheTemplates).
Regards,
z
