On Thursday, 7 February 2013 at 10:32:38 UTC, Walter Bright wrote:
On 2/7/2013 2:05 AM, deadalnix wrote:
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright
wrote:
The point is, there must always be a balance of competing
interests. That's
certainly true here.
That is an assertion not an argument.
Try designing anything by using one overriding principle - you
won't get a useful result. Designs are always tradeoffs, always.
Ho yeah, I'm not arguing against that. But what is seen as
conflicting goal often aren't.
Does C# always allow taking the address of a getter's return
value? I don't
know, but I'd be surprised if it did.
C# don't have address of. It isn't a system language. Even if
you consider the
whole stuff without the address problem, the D way is
different than C#'s.
It's a different language, with a different view of things.
Direct comparisons between D and C# need to take that into
account.
The 'funny' things is that C#'s would cause syntax problem
issue with address of,
where D does.
I don't understand this sentence.
In C#, foo.bar won't execute bar's method of foo. It will get
what is called in D a delegate. foo.bar() execute that delegate.
It remove the need for &foo.bar altogether, so with that
mechanism in D, no problem with & operator.
Scala does even one step further by executing the method, or not,
depending on what is expected, proving that optional () are
compatible with.
Back to D, we have void function() foo; foo is declared as a
function here. However, void bar() {} will also be called a
function, even if the entity represented by foo and bar are
completely different.
When you do foo = &bar, you get a pointer on foo's instruction.
Here foo isn't a function in the D sense, but an Array of CPU
instruction, or something like that. This entity, coming from
C/C++ hasn't ANY useful usage except taking the address of to get
a function. Wanting to keep that useless entity is the source of
most trouble with the & syntax, and also on previous DIP (not
that one).
How does one prove anything is a "good thing"?
Proven may be strong, but you can't refute that some things are
better than others.
Yes. But I don't see the issue. &foo cannot bind to an alias
parameter, nor
can foo().
void function() foo can.
Sure. But I'm lost at what your point is with that example.
Now you can pass several object to templates alias parameters,
that will behave differently in slightly different subtle ways.
For no real good reason.
I don't think it is, and looking at other languages choices,
I'm not alone.
Given the vast variety and complexity of languages out there,
for every example of A you can find, I can find examples of !A.
It's not really useful, after all, if other languages got it
all right, there's no point to D.
If A is the instruction pack entity type mentionned above, you'll
find pretty hard to find a !A if we exclude C and C++ (well and
D, but it is kind of excluded if look for references). I don't
pretend none exists, but it seems pretty hard to find one.
Because the idea is bad for everybody : it make the language more
complex, harder to implement compiler/tooling for, can conflict
with other features, and worse, have no benefice.
This is a bad idea in all possible way. Actually so bad that even
PHP don't implement it.
This kind of thing always seems simple of some cases, but ends
up creating a
huge minefield of special case when you start to combine
feature together. And
this is something that most D users experiences.
I believe that Andrei's proposal resolves these.
He does so by adding special cases. That is the problem with
special cases, they multiply themselves faster than rabbits.
It result in users not using advanced D features (see HIGGS
topic for instance,
or many codebases on github in general) or user having
trouble. It is often
advised to stay away form advanced features of D for
production quality stuff
and I have to say I share the observation. Working on large
codebase (well large
. . . for a personal project, but clearly ridiculous compared
to many companies
codebase : ~25 000LOC) using advanced features of D, I run in
such troubles
almost on a daily basis, and have developed some knowledge of
area of the
language I should not even try to go in.
This is exactly why we're going through this exercise with the
properties.
It is clear that the property improvement proposed by Andrei is a
great step forward. However, the &foo.bar that return the
delegate when bar is a property is exactly the kind of stuff that
are waiting to explode.
Yes, this DIP remove the syntactic ambiguity (does this take the
delegate or the address of the result ?) but that is barely it.
I'd say that the fact that & have a meaning is way more
problematic than the fact that it is not possible to take the
resulting address.
