First Draft: cast(ref T)... as shorthand for *cast(T*)&...

[Quirin Schroll]

On Thursday, 23 January 2025 at 19:08:16 UTC, Dom DiSc wrote:
> On Thursday, 23 January 2025 at 01:56:32 UTC, Quirin Schroll 
> wrote:
>
>> `cast` should only ever do `@safe` casts, and be required for 
>> stuff like `cast(ushort) myInt`.
>
> For this, I wish ushort(myInt) would work. This would safe a 
> LOT of unneccessary text and keep cast() for the more dangerous 
> things.
>
> But at the moment the compiler rejects that: "cannot implicitly 
> cast myInt of type int to ushort". I would never consider 
> ushort(x) "implicit". It really doesn't get any more explicit 
> than this :-(

Well, at this point, we’re arguing syntax. Being able to request 
an implicit conversion is important when a language has type 
inference. There are situations in which you don’t want to 
truncate, but the type something has isn’t the type it needs to 
be. `ushort(…)` is an explicit request for an implicit cast.

If you made `ushort(…)` an explicit request for a truncating 
cast, how do I do an explicit request for an implicit cast?

> Allowing explicitly calling the constructor of a smaller type 
> to truncate values could easily get allowed without breaking 
> any existing code.
> Especially because working with small types requires this cast 
> over and over because every operation extends them to int.

My sense is that the smaller types are only really valuable as 
storage, i.e. for arrays. The 2x or 4x space can make a 
difference (using `int[]` instead of `short[]` or `byte[]`) in 
some contexts. For a local variable, it makes almost never a 
difference.