On 12/11/10 2:42 CST, spir wrote:
On Fri, 10 Dec 2010 21:25:49 -0500
Michel Fortin<michel.for...@michelf.com> wrote:
On 2010-12-10 17:12:16 -0500, Don<nos...@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