== Quote from Stewart Gordon (smjg_1998@yahoo.com)'s article
> "# Casting a value v to a struct S is now rewritten as S(v).
> # Initializing a struct S from a value v is now rewritten as S(v)."
> It took me a moment to realise what you meant by this.
Can you please enlighten the rest of us too?

Boris Kolar wrote:
> == Quote from Stewart Gordon (smjg_1998@yahoo.com)'s article
>> "# Casting a value v to a struct S is now rewritten as S(v).
>> # Initializing a struct S from a value v is now rewritten as S(v)."
>> It took me a moment to realise what you meant by this.
>
> Can you please enlighten the rest of us too?
S(v) ==> S.opCall(v), that is calling the static opCall of struct S with v
as an argument.
--
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

- Casting a value v to a struct S is now rewritten as S(v).
I'm 100% against this. This is what C++ does, and it conflates
construction and casting; with some VERY simple examples (such as the
first one we think of when we think of additional types, bignums),
there's an ambiguous conflict because one of the constructors should
have a count of how many digits you want - and one of the casters takes
an integer for a value to initialise to. My solution at the time was to
add a dummy argument to the constructor so that the compiler didn't try
to match them, which is absurd.
I don't know why C++ was designed like this when its error was so
blatant, but D doesn't need to replicate its mistake. "S.opCastFrom (v)"
please, except that it shouldn't be static either.