DMD 0.177 release

[Leopold Walkling]

Jarrett Billingsley schrieb:
> "Walter Bright" <newshound at digitalmars.com> wrote in message 
> news:elnv14$r2d$1 at digitaldaemon.com...
> 
>> For whatever the merits of opCall vs this(), efficiency is NOT a problem 
>> with either, and is not a reason to choose one or the other. The generated 
>> code is the same.
>>
>> Under the hood, they are the same. Both take a hidden pointer to where the 
>> result is stored. The rest is window dressing.
> 
> Alright then.  All I've got then is the orthogonality argument.  But you 
> won't listen to that either.
> 
> People will come to D from C++ and C# and ask "where are constructors in 
> structs?" and we'll say "you have to use static opCall."  And they'll ask 
> "why?"  And all we'll be able to do is shake our heads, sigh, and say "I 
> don't know."
> 
> For the last time, even though you don't care: we have been using static 
> opCall as a WORKAROUND.  As in *we never intended for that to be the 
> canonical method of constructing a struct*.  I don't think anyone would 
> complain if they were given a consistent, logical method of initializing any 
> aggregate type. 
> 
> 

To me another big problem is the cast to a struct. How could anyone, who 
is new to D/ didn't study the spec enough expect, that a cast to a 
struct is done by calling the "opCall". One of those who came from C++ 
(like me too) would expect the static opCall as the equivalent to those 
rather rarely used C++-operator()() overloads.
What could one answer if some of them ask why it's like this? Couldn't 
there just be another name than static opCall?

Then, to keep it from being ambigous, there could be a change of the 
let's say opCreate syntax. It doesn't has to be like in C++, I imagine 
something in the direction of static struct initializers:

struct A
{
	int i, j;
}

int v = 9;
A a = A:{a:10, j:v /*not only constants*/};