On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu wrote:
> In brief:
>
> * Optional parens stay.


This syntax sugar only helps in chained-UFCS calling. Why allowing it everywhere, that is even if the function's name is not followed by a dot?

like this: Obj1.action1.action2.action3(); It is clearer than Obj1.action1().action2().action3(); and, still, does not allow something like Obj1.action1; requiring an Obj1.action1(); instead.

> * Just mentioning a function or method without parens does NOT automatically take its address. (This is a change from the current behavior.)

If you stick to the above "optional only if followed by a dot"-paradigm, you could maintain the behavior, except in that UFCS-chains, where it doesn't matter anyway what mentioning a function or method without parens returns, since one assumes invocation in this kind of chains.

> * 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.

And if the returned value is a parameterless function, shouldn't that be callable without parens?

> * Write properties (using @property) may only be used in the assignment form (no function-style call allowed).

On 02/03/2013 11:24 PM, eles wrote:
> On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu wrote:
>> In brief:
>>
>> * Optional parens stay.
>
>
> This syntax sugar only helps in chained-UFCS calling.
> ...

Nope.

a.map!(a=>2*a);

> ...
>> * 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.
>
> And if the returned value is a parameterless function, shouldn't that be
> callable without parens?
> ...

No, it shouldn't. The rewrite is (rightfully) not applicable to expressions of first class function types. The only reason why the implicit calling and @property approaches are workable is because the language also supports non first class functions (inherited directly from C).

On 02/03/2013 09:16 AM, Andrei Alexandrescu wrote:
> ...
>
> * Just mentioning a function or method without parens does NOT
> automatically take its address. (This is a change from the current
> behavior.)
>

(No, it is not.)

From the DIP:

"This proposal sustains that optional parentheses should stay in. That means, if a function or method may be called without arguments, the trailing parens may be omitted. [...] The same goes about methods: [...] However, that's not the case with function objects, delegate objects, or objects that implement the function call operator. [...]"

Should also mention static opCall.

The section does not mention what happens with first class callables that are invoked via UFCS. In particular, the validity of eg. the following code (which currently is valid) is not specified:

enum foo = (int x)=>x;
static assert(2==2.foo);

On Sun, Feb 03, 2013 at 03:16:08AM -0500, Andrei Alexandrescu wrote:
> Walter and I have had a discussion on how to finalize properties.
> 
> http://wiki.dlang.org/DIP23
[...]

+1.

I think this proposal (1) addresses the most important issues with the current implementation of @property, and (2) is probably one of the simplest ways to fix current issues without introducing too many changes and new features. I vote for this.


T

-- 
Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr

I'm glad Johannes brought up all these cases. They all need to go into the DIP.

On 2/3/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> So instead of having behavior based on whether there are any parens involved, you would have:
>
> &a.prop;  // address of return value
> &(a.prop)  // ditto
> a.prop.addrOf  // address of property function

So, thoughts on this?

On 2/3/13 3:16 AM, Andrei Alexandrescu wrote:
[snip]

Some more thinking got me to three simple principles that guide the proposed property design:

http://wiki.dlang.org/DIP23#In_a_nutshell

I think most, if not all, detailed rules derive from these.


Andrei

On Sun, Feb 03, 2013 at 08:30:48PM -0500, Andrei Alexandrescu wrote:
> On 2/3/13 3:16 AM, Andrei Alexandrescu wrote:
> [snip]
> 
> Some more thinking got me to three simple principles that guide the proposed property design:
> 
> http://wiki.dlang.org/DIP23#In_a_nutshell
> 
> I think most, if not all, detailed rules derive from these.
[...]

This is precisely the kind of simplicity we need to resolve this issue. I fully concur.


T

-- 
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.

On Sunday, February 03, 2013 20:30:48 Andrei Alexandrescu wrote:
> On 2/3/13 3:16 AM, Andrei Alexandrescu wrote:
> [snip]
> 
> Some more thinking got me to three simple principles that guide the proposed property design:
> 
> http://wiki.dlang.org/DIP23#In_a_nutshell
> 
> I think most, if not all, detailed rules derive from these.

Technically, the bit about having exactly one or exactly two parameters is wrong, unless you're counting the invisible this pointer/reference in that. Member property functions end up with exactly zero or exactly one parameters.

- Jonathan M Davis

On Monday, 4 February 2013 at 01:30:49 UTC, Andrei Alexandrescu wrote:
> I think most, if not all, detailed rules derive from these.

One does not, the strange special case for taking the address of a property.

I'd REALLY urge you to explore alternative solutions, such as the one proposed by Andrej, before introducing an abomination like distinguishing between "&a" and "&(a)".

There is no way such strange behavior could be explained in a way that is coherent with the rest of the language.

I found that when you are working on a complex problem and have a solution that seems to work for everything except a little detail, the best approach often is to step back a bit and have an entirely fresh look at that area again, but now taking the rest of your design as a given.

Introducing a rule by which parenthesizing an expression in a way that does not change precedence suddenly causes a difference in behavior certainly wouldn't be among the first ideas coming to my mind this way.

David