Destructors, const structs, and opEquals

[Andrei Alexandrescu]

On 12/10/10 6:25 PM, Michel Fortin wrote:
> On 2010-12-10 17:12:16 -0500, Don <nospam at nospam.com> said:
>
>> Steven Schveighoffer wrote:
>>> To summarize for those looking for the C++ behavior, the equivalent
>>> would be:
>>>
>>> void foo(auto ref const Widget)
>>
>> That use of 'auto' is an abomination.
>
> One problem I'm starting to realize is that we now have so many
> available qualifiers for function parameters than it's really easy to
> get lost.
>
> In D1 it was simple: "in" for regular arguments (the default),
> "inout"/"ref" for passing arguments by refrence, and "out" for output
> arguments. They all had clear semantics and not too much overlap.
>
> In D2, we've lost this simplicity. Add "const/immutable/shared", add
> "scope", change "in" as an alias for "const scope", give "inout" a
> totally new meaning, keep "ref" and "out" the same except that now "ref"
> can be prefixed with "auto" to give it a double meaning... choosing the
> right modifiers for function parameters is getting extra complicated.
>
> Have we lost track of one of D's principles, that doing the right thing
> should be the easiest way to do things? To me it looks like we're adding
> more and more ways to pass arguments because the defaults are failing
> us. Perhaps it's time to revisit how arguments are passed by default.
>
> As for "auto ref", if we're to keep it I think it'd be much better if it
> was a keyword of its own, such as "autoref". Having modifiers is one
> thing, but having modifiers that apply to modifiers is getting a little
> hard to parse in my head. This is not unprecedented, in English when one
> qualifier apply to another and it becomes hard to read we group them by
> adding a hyphen between the two.

It's sort of ironic. You just argued for the utility of, and 
implemented, another type constructor yourself!

Andrei