For whom is

[Andrei Alexandrescu]

On 12/11/10 2:42 CST, spir wrote:
> On Fri, 10 Dec 2010 21:25:49 -0500
> Michel Fortin<michel.fortin at michelf.com>  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.
>
> I totally agree. This extends to all sorts of D qualifiers:
> abstract alias const extern final immutable in inout lazy nothrow out override private protected public pure ref scope shared static.
>
> I'm afraid D2 in on the track of becoming a language for the elite. What do you think?
> (I'm certain it is possible to make most languages simpler and as powerful, if we use clever designer brains with this target in mind. The issue I see with all those features is: what do they mean? Note What is absent from D docs is the purpose and meaning of most elements of the language. Probably obvious for their designers, but who else is supposed to use them?)

The concern is valid. On the other hand, D is in the business of 
defining precise interfaces. Let's see how the keywords you mentioned 
(which are only very loosely related; most are not qualifiers) are up 
the task:

* abstract introduces an entity that is meant to be

* alias introduces symbolic names for elaborate constructs.

* const specifies that the callee will exact no change on the transitive 
state of an object.

* extern interfaces D with other languages

* final prevents (further) overriding of a method

* immutable guarantees strong data immutability.

* in is a vestige now used for const, and a syntactic component of contracts

* inout obviates (modulo current implementation shortcomings) the 
necessity of defining identical methods, one for each qualifier

* lazy sucks

* nothrow specifies that a function will never throw

* out specifies that the parameter is meant only for output

* override is useful to clarify that overriding is intended (btw even 
C++0x adopted it although it has tried for years to make-do without)

* private * protected * public specify access rights

* pure guarantees functional semantics for a function

* ref indicates pass and return by reference

* scope is fuzzy at the time being as a storage class, but is a terrific 
instruction

* shared is instrumental to threading with guarantees

* static specifies, well, a number of things :o)

We stand to lose the ability to express designs clearly and in good 
detail whichever of the above we eliminate. What do we take away?


Andrei