On 2013-11-21 07:06, Walter Bright wrote:

> The next release is going to be about bug fixes, not introducing
> regressions from new features(!). It's a short release cycle, anyway.

You better watch what happens deep inside the pull requests then :)

-- 
/Jacob Carlborg

On 21.11.2013. 4:14, Manu wrote:
> It would be nice to have a commitment on @property.
> Currently, () is optional on all functions, and @property means nothing.
> I personally think () should not be optional, and @property should
> require that () is not present (ie, @property has meaning).
> 
> This is annoying:
>   alias F = function();
> 
>   @property F myProperty() { return f; }
> 
>   Then we have this confusing situation:
>     myProperty(); // am I calling the property, or am I calling the
> function the property returns?
> 
> This comes up all the time, and it really grates my nerves. Suggest; remove @property, or make it do what it's supposed to do.

Fix it!

struct S {
  auto f1 () { return 1; }
  auto f2 () { return { return 2; }; }

  @property auto p1 () { return 5; }
  @property auto p2 () { return { return 6; }; }
}

unittest {

  S s1;

  // don't breat current function call behavior
  // don't deal with optional () now
  // (but also don't break their behavior)
  assert(s1.f1 == 1);
  assert(s1.f1() == 1);

  assert(s1.f2()() == 2);
  auto fv = s1.f2;
  assert(fv() == 2);

  // make sure @propery works as described
  // in http://dlang.org/property.html#classproperties
  assert(s1.p1 == 5);
  static assert(!__traits(compiles, s1.p1() == 5));

  assert(s1.p2() == 6);
  static assert(!__traits(compiles, s1.p2()() == 6));

  auto pv1 = s1.p1;
  assert(pv1 == 5);

  auto pv2 = s1.p2();
  assert(pv2 == 6);

}

This test is according to the documentation and as far as I remember everyone agrees that this is how @property should behave.

I think, @property should be removed. Requiring to mark properties with an annotation to make them work unambiguously is bug-prone, because you can forget to do so and nothing will warn you.

On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:
> It would be nice to have a commitment on @property.
> Currently, () is optional on all functions, and @property means nothing.
> I personally think () should not be optional, and @property should require
> that () is not present (ie, @property has meaning).
>
> This is annoying:
>   alias F = function();
>
>   @property F myProperty() { return f; }
>
>   Then we have this confusing situation:
>     myProperty(); // am I calling the property, or am I calling the
> function the property returns?

The latter. Property should be enforced properly.

> This comes up all the time, and it really grates my nerves.
> Suggest; remove @property, or make it do what it's supposed to do.


If you combine:

1) enforced property syntax, no parens allowed

2) & always applies to a parenthesis-less function, not it's result

3) properties decay to normal functions when they have their address taken

4) For template params: pass function symbol if possible, otherwise evaluate and pass the result.

then we have a solved problem, while allowing people to keep their nice pretty ()-less UFCS chains, no?

On 11/21/2013 02:04 PM, John Colvin wrote:
>
>
> 3) properties decay to normal functions when they have their address taken

No, why?

On Thursday, 21 November 2013 at 13:28:01 UTC, Timon Gehr wrote:
> On 11/21/2013 02:04 PM, John Colvin wrote:
>>
>>
>> 3) properties decay to normal functions when they have their address taken
>
> No, why?

Sorry, I forgot to add:
5) parenthesis are enforced for all calls on all callables other than functions, including function pointers and delegates.

In combination with 3 this prevents any ambiguity when dealing with addresses of functions. Otherwise they become impossible to manipulate as they would evaluate to their result anywhere they're mentioned in code. Some examples of things working how I suggest:

@property auto f() { return 3; }
auto p = &f;
auto q = p;   //q is address of f
auto r = q(); //r is 3

auto g() { return &f; }

auto a = g(); //a is address of f
auto b = g;
assert(a is b);

@property auto z() { return &f; }
auto c = z; //c is address of f

On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote:
> On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:
>> It would be nice to have a commitment on @property.
>> Currently, () is optional on all functions, and @property means nothing.
>> I personally think () should not be optional, and @property should require
>> that () is not present (ie, @property has meaning).
>>
>> This is annoying:
>>  alias F = function();
>>
>>  @property F myProperty() { return f; }
>>
>>  Then we have this confusing situation:
>>    myProperty(); // am I calling the property, or am I calling the
>> function the property returns?
>
> The latter. Property should be enforced properly.
>
>> This comes up all the time, and it really grates my nerves.
>> Suggest; remove @property, or make it do what it's supposed to do.
>
>
> If you combine:
>
> 1) enforced property syntax, no parens allowed
>
> 2) & always applies to a parenthesis-less function, not it's result
>
> 3) properties decay to normal functions when they have their address taken
>
> 4) For template params: pass function symbol if possible, otherwise evaluate and pass the result.
>
> then we have a solved problem, while allowing people to keep their nice pretty ()-less UFCS chains, no?

I forgot to add:

5) parenthesis are enforced for all calls on all callables other than functions, including function pointers and delegates.

On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote:
> 3) properties decay to normal functions when they have their address taken
>
Is there some reason why we _need_ to be able to take the address of properties?  I've yet to see a good argument in favour of it, and I've seen several against.  I think that whole idea is a misfeature that won't be missed.

-Wyatt

On Thursday, 21 November 2013 at 14:19:22 UTC, Wyatt wrote:
> On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote:
>> 3) properties decay to normal functions when they have their address taken
>>
> Is there some reason why we _need_ to be able to take the address of properties?  I've yet to see a good argument in favour of it, and I've seen several against.  I think that whole idea is a misfeature that won't be missed.
>
> -Wyatt

Are there any arguments against it within the context of the proposal i'm making? At the very least the obvious problems disappear.

If the consensus was that the address of a property was an unnecessary concept then it could be disallowed and point 3) of my list disregarded. The rest stands separate from this issue.

On Thursday, 21 November 2013 at 13:28:01 UTC, Timon Gehr wrote:
> On 11/21/2013 02:04 PM, John Colvin wrote:
>>
>>
>> 3) properties decay to normal functions when they have their address taken
>
> No, why?

properties should be just "variables without address". that is, taking the address of a property should be forbidden.

if one needs to take the address, then the programmer should not implement it as a property.

if one programmer tries to convert an existing variable to a property, then he/she should remove addresses where required.

why so much hassle to think "variable" when speaking about "property"?