On Monday, 4 February 2013 at 02:18:08 UTC, David Nadlinger wrote:
> 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 su<ch strange behavior could be explained in a way that is coherent with the rest of the language.

As another data point, Walter wrote a while ago himself: »I'm just arguing against the e and (e) solution as (perhaps) causing more ambiguity problems«.

David

2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>

> 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<http://wiki.dlang.org/DIP23#In_a_nutshell>


> 2. A @property may have EXACTLY ONE or EXACTLY TWO parameters, counting
the implicit this parameter if at all. The ONE-parameter version is ALWAYS a getter, and the TWO-parameter version is ALWAYS a setter. There's no variadics, defaulted parameters, and such.

Unfortunately, I can present a counterexample.

struct S {
    static int value;
    static @property int foo() { return value; }
    static @property void foo(int n) { value = n; }

}
void main() {
    int n = S.foo;
    S.foo = 1;
}

Should they be disallowed, as like module level properties?

Kenji Hara

On Monday, 4 February 2013 at 02:18:08 UTC, David Nadlinger wrote:
> 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.
>

The problem we are dealing with here isn't complex. It is made complex artificially.

We are trying to make @properties behave like fields, but hey in this case I want it to behave like a function . . . oh yeah so in this special case, I have to workaround, ho and here and here as well, oh damn, that is complicated.

Same goes when conflating the function with it's return value (which optional () is about).

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

By trying to make things easy, we miss that the important point is to make them simple.

On 02/04/2013 03:23 AM, kenji hara wrote:
> 2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> <mailto:SeeWebsiteForEmail@erdani.org>>
>
>     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
>     <http://wiki.dlang.org/DIP23#In_a_nutshell>
>
>
>  > 2. A @property may have EXACTLY ONE or EXACTLY TWO parameters,
> counting the implicit this parameter if at all. The ONE-parameter
> version is ALWAYS a getter, and the TWO-parameter version is ALWAYS a
> setter. There's no variadics, defaulted parameters, and such.
>
> Unfortunately, I can present a counterexample.
>
> struct S {
>      static int value;
>      static @property int foo() { return value; }
>      static @property void foo(int n) { value = n; }
>
> }
> void main() {
>      int n = S.foo;
>      S.foo = 1;
> }
>
> Should they be disallowed, as like module level properties?
>
> Kenji Hara

Probably. (static essentially means module-level, but in a potentially nested name space.)

On 02/04/2013 03:28 AM, deadalnix wrote:
> On Monday, 4 February 2013 at 02:18:08 UTC, David Nadlinger wrote:
>> 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.
>>
>
> The problem we are dealing with here isn't complex. It is made complex
> artificially.
>

It is not even made complex. It is quite obvious how things should work. (and &a vs &(a) is not it.)

> We are trying to make @properties behave like fields,

(Syntactically.)

> but hey in this  case I want it to behave like a function . . .

This is the step that must be reconsidered.

> oh yeah so in this
> special case, I have to workaround, ho and here and here as well, oh
> damn, that is complicated.
>
> Same goes when conflating the function with it's return value (which
> optional () is about).
>

Certainly not! & is the syntactic element distinguishing functions from return values, not (). Optional & would be about conflating the function with its return value. (Scala basically does this, but instead of prefix & they use suffix _.)

>> 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.
>>
>
> By trying to make things easy, we miss that the important point is to
> make them simple.

Most of this stuff is simple enough. Have you implemented optional parens already?

On Monday, 4 February 2013 at 02:28:39 UTC, deadalnix wrote:
> On Monday, 4 February 2013 at 02:18:08 UTC, David Nadlinger wrote:
>> 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.
>>
>
> The problem we are dealing with here isn't complex. It is made complex artificially.
>
> We are trying to make @properties behave like fields, but hey in this case I want it to behave like a function . . . oh yeah so in this special case, I have to workaround, ho and here and here as well, oh damn, that is complicated.
>
> Same goes when conflating the function with it's return value (which optional () is about).

Not sure I'm following – you are arguing that the whole endeavor is futile as long as we keep parens-less function calls?

I actually think that DIP23 is a big step in the right direction, given that parens-less function calls are *very* unlikely to go away. Contrary to some of the previous proposals, it's actually a principled approach, like Adam and others (including me) have asked for. Now it's just a matter of getting the details right.

>> 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.
>>
>
> By trying to make things easy, we miss that the important point is to make them simple.

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.

David

On 2/3/13 9:23 PM, kenji hara wrote:
> 2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> <mailto:SeeWebsiteForEmail@erdani.org>>
>
>     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
>     <http://wiki.dlang.org/DIP23#In_a_nutshell>
>
>
>  > 2. A @property may have EXACTLY ONE or EXACTLY TWO parameters,
> counting the implicit this parameter if at all. The ONE-parameter
> version is ALWAYS a getter, and the TWO-parameter version is ALWAYS a
> setter. There's no variadics, defaulted parameters, and such.
>
> Unfortunately, I can present a counterexample.
>
> struct S {
>      static int value;
>      static @property int foo() { return value; }
>      static @property void foo(int n) { value = n; }
>
> }
> void main() {
>      int n = S.foo;
>      S.foo = 1;
> }
>
> Should they be disallowed, as like module level properties?

Yes. No static properties.

Andrei

On 2/3/13 9:17 PM, David Nadlinger wrote:
> 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)".

Andrej's proposal is nice, but I think you're wrong about this. We're already there - &a.b means something (a delegate) which is not decomposable into smaller parts.

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

I disagree.

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

I agree with the general thought.

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

I really think you are wrong about this. Parenthesizing has nothing to do with this. &a.b is punctuation that creates an indivizible unit.


Andrei

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. Think it over, and compare it with the language semantics even today.

Andrei

On Monday, 4 February 2013 at 03:11:25 UTC, Andrei Alexandrescu wrote:
>> There is no way such strange behavior could be explained in a way that
>> is coherent with the rest of the language.
>
> I disagree.

Then I'm eager to hear your explanation. Parentheses in an expression usually change precedence. Here they do something entirely different.

>> 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.
>
> I really think you are wrong about this. Parenthesizing has nothing to do with this. &a.b is punctuation that creates an indivizible unit.

a.b already is an indivisible unit, the result of the function call.

David