On 2/4/13 9:25 AM, Timon Gehr wrote:
> On 02/04/2013 03:05 PM, Andrei Alexandrescu wrote:
>> I think the sensible disambiguation is to
>> have &fun take the address of fun and the other two take the address of
>> fun's result.
>>
>
> No! &fun and &(fun) are the same thing. Functions that get their address
> taken are not implicitly invoked. (Again, Scala agrees.)
>
> The rules are straightforward:
>
> A non-@property function name 'foo' denotes a function invocation
> without arguments iff it does not occur in one of the following contexts:
>
> 1. foo(...) // explicitly called
> 2. &foo // address taken
> 3. ...!(...,foo,...) // template argument (well, that's what DMD
> currently does)
> 4. alias ... = foo; // aliased

The problem with (3) is that it creates a rule that gives different meaning of expressions inside &(...) and outside it. Consider:

&foo -> fine, takes the address of foo
&(foo) -> parens don't matter, sweet, still takes the address of foo
&( condition ? foo : bar ) -> hum, I guess takes the address of foo or bar
&( { auto a = foo; ... return c ? foo : bar; }() ) -> what???

So this is essentially a rule that makes the same give expression have a meaning inside &( ... ) and a different meaning outside.

In &expr.name and &(expr.name), that's it - expr may be arbitrarily complicated, but the construct must always end with a method name. In &name and &(name), it's even simpler - it's just punctuation.


Andrei

On 2/4/13 9:34 AM, Timon Gehr wrote:
> On 02/04/2013 04:13 AM, Andrei Alexandrescu wrote:
>> On 2/3/13 9:58 PM, David Nadlinger wrote:
>>> My point is precisely that. I think there are much simpler solutions
>>> than adding some magic properties to a pair of parentheses in the right
>>> position, even if it might look like a convenient hack.
>>
>> I don't think it's a hack at all.
>
> It is a horrible hack. Why is this not obvious?

I think it's because it's a matter in which reasonable people may disagree.

Andrei

On 2/4/13 11:01 AM, Steven Schveighoffer wrote:
> @property int foo();
>
> auto x = &foo; // error
> int delegate() x = &foo; // ok

That's an interesting idea. I'm a bit weary about it though. At least for properties I'm inclined toward starting real tight with address-of disabled and relax the rules later.

Andrei

On 2/4/13 1:15 PM, Rob T wrote:
> BTW, I am wondering if the idea of "memberspaces" was considered, and if
> it was considered, then why was it dropped?

An idea that departs considerably from the current status in D has a disadvantage compared to an idea that makes things work within the @property framework.

Andrei

On 2/4/13 2:04 PM, Jonathan M Davis wrote:
> We could save a lot of boilerplate code if we can simply make it variables and
> property functions guaranteed to be swappable without breaking code.

I think this is quite powerful. The way we can do this is by making properties emulate a subset of actual variables.

Andrei

On 2/4/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> I think it's because it's a matter in which reasonable people may disagree.

Well, Walter seemed to agree with us before: d.puremagic.com/issues/show_bug.cgi?id=9062#c13

And even Kenji who likes it seemed to close his pull: https://github.com/D-Programming-Language/dmd/pull/1310#issuecomment-12524998

I don't know what changed their opinions now.

On Monday, February 04, 2013 17:28:24 Andrei Alexandrescu wrote:
> On 2/4/13 2:04 PM, Jonathan M Davis wrote:
> > We could save a lot of boilerplate code if we can simply make it variables and property functions guaranteed to be swappable without breaking code.
> I think this is quite powerful. The way we can do this is by making properties emulate a subset of actual variables.

Yes. There are things that propery functions need to emulate from normal variables (hence the rewrites with ++ and += and whatnot), and there are of course things that they can't emulate (like taking the address of a variable). But what we also need is a way to mark a variable as a property and then make it so such a variable and property functions have the same capabilities so that you're guaranteed to be able to swap between the two without breaking code. As soon as one of the two has capabilities that the other doesn't have, or there's a major semantic change between them (like taking the address works on one but not the other or the type returned by taking the address differs), then you can't do that.

Which is why I would argue that we need to be able to mark variables with @property (which either makes it so that you can't do anything with them that you can't do with a property function or makes it so that it lowers to property functions for getting and setting), and we need to disallow taking the address of property functions as well as anything else that you could do with a variable that we can't emulate with a property function.

- Jonathan M Davis

On 2/4/2013 6:05 AM, Andrei Alexandrescu wrote:
> Couldn't AddressOf use "&(" + exp + ")"?
>
> I thought more about this. The problem remains even without @property, due to
> optional parens in function invocation. Consider:
>
> ref int fun() { ... }
> auto p1 = &fun;
> auto p2 = &(fun);
> auto p3 = &(fun());
>
> What are the types of the three? The optional parens in invocation require some
> disambiguation. I think the sensible disambiguation is to have &fun take the
> address of fun and the other two take the address of fun's result.

The only time it is valid to take the address of a function's return value is if the function returns a ref.

But I also would think that it's a suspicious practice to take the address of a ref. We've disallowed it in other circumstances, why allow it here? If a function intends for someone to take the address of the return ref, shouldn't the function return a pointer instead?

If taking the address of a ref is disallowed, then the above problem goes away. &fun, in all its variants, takes the address of the function.

On Monday, 4 February 2013 at 11:47:25 UTC, Andrei Alexandrescu wrote:
> Yes, if we disallowed address taking things would get a bit simpler.
>

The address taking of ?

On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu wrote:
> Walter and I have had a discussion on how to finalize properties.
>
> http://wiki.dlang.org/DIP23
>
> We got input from DIP21 (which we didn't want to clobber, hence the new DIP) and the recent discussion.
>
> The proposal probably won't be accepted in its current form because it breaks some code. We hope to bring it to good shape with everyone's help.
>
> In brief:
>
> * Optional parens stay.
>
> * Just mentioning a function or method without parens does NOT automatically take its address. (This is a change from the current behavior.)
>
> * Read properties (using @property) work as expected with the mention that they may NOT be called with the parens. Any parens would apply to the returned value.
>
> * Write properties (using @property) may only be used in the assignment form (no function-style call allowed).
>
> It is understood that the current proposal is just a draft and there must be quite a few corner cases it doesn't discuss. We also understand it's impossible to reconcile all viewpoints and please all tastes. Our hope is to get to a point where the rules are self-consistent, meaningful, and complete.
>
>
> Destroy.
>
> Andrei

http://forum.dlang.org/thread/ririagrqecshjljcdubd@forum.dlang.org

Smash.