Destructors, const structs, and opEquals

[Michel Fortin]

On 2010-12-10 21:28:43 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 12/10/10 6:25 PM, Michel Fortin wrote:
>> 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!

Yeah, I know it's a little ironic. There's a difference though.

The problem I'm trying to illustrate here is that you'll need to be an 
expert to choose the right one depending on the situation. How many 
times have you seen someone pass std::string by copy in C++? You need a 
lot of training to get this right all the time because it's not the 
simpler way to pass parameters. Will the compiler complain when you 
pass a parameter by value instead of passing it by 'auto ref'?

As for the optional 'ref' suffix I added in my patch for tail-const, 
it's simply the continuation of the same syntax for pointers. It's not 
a type constructor. It's only a way to make explicit the 
already-existing implicit reference that classes have so you can apply 
type constructors separately to it. I doubt people will get it wrong 
often because in most situations the compiler will complain when you 
should have made the ref mutable and you haven't. There's no 
inefficiency by default here.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/