On Thursday, 24 January 2013 at 13:34:08 UTC, Artur Skawina wrote:
> On 01/24/13 12:50, mist wrote:
>> But looking at other comments this does not seem popular :(
>
> Language design is not a popularity contest.
>
> artur

Well most discussions seems to flow around simple preference conflict of beautiful UFCS vs consistent function calls. And all compromises tend to explode in difficulty once delegates and function pointers are taken into consideration. I find consistent and unambiguous call syntax more important.

On 2013-01-24 14:28, Sönke Ludwig wrote:

> 1. Normal function calls _may_ omit parentheses, but "a = b" is _not_ interpreted as "a(b)"
> 2. @property functions can _not_ be called with parentheses and "a = b" _is_ interpreted as "a(b)"
> 3. Calling a normal function always returns its return value

+1

-- 
/Jacob Carlborg

On Thursday, 24 January 2013 at 13:28:48 UTC, Sönke Ludwig wrote:
> Am 24.01.2013 09:34, schrieb Walter Bright:
>> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>> 
>> Perhaps we should revert to a simple set of rules.
>
> I think Adam D. Ruppe has proposed this in the past and, although I don't really like omitting
> parentheses on ordinary function calls in general (apart from UFCS template functions), it's clear,
> simple and I think everyone could be happy with it:
>
> 1. Normal function calls _may_ omit parentheses, but "a = b" is _not_ interpreted as "a(b)"
> 2. @property functions can _not_ be called with parentheses and "a = b" _is_ interpreted as "a(b)"
> 3. Calling a normal function always returns its return value
>

This greatly impairs functional style. Just as you demonstrated nicely with return values, this one cause the same problem with arguments (either to template or functions).

>> 
>> 1. Empty parens are optional. If there is an ambiguity with the return value taking (), the () go on
>> the return value.
>
> This sounds like a recipe for disaster. Thinking about generic code calling functions... it would
> surely be very surprising to see how f() sometimes does not return ReturnType!f, but something
> completely different. It would also break all existing code that currently expects f() to simply
> return its return value. More importantly, adding or removing an opCall or changing the return type
> of a function would possibly silently change the meaning of code that calls the function.
>
> IMO it is also utterly unexpected/counter-intuitive for a seeming function call not to return its
> return value, but call it and return the result.
>

Great explanation on how it mess up return values when using very functional style.

On Thursday, 24 January 2013 at 13:43:41 UTC, Jacob Carlborg wrote:
> On 2013-01-24 14:01, mist wrote:
>
>> And yet it must have been done at some point. With some year-ahead
>> announcement or anything like that, but it was a horrible design error
>> in first place which needs to be fixed.
>
> Yes, it was a horrible design error but it didn't break any code because the -property flag is optional.

Design error was to not force "-property" since the very beginning. Now good decisions are kind of doomed to break code because restrictions were (and still are) too lax and a lot of inconsistent code is somewhere out there.

This is exactly why I voted for LTS + rolling-release model. D is still far from the point where design specs can be frozen and breaking code prohibited. Those still have mistakes.

On Thursday, 24 January 2013 at 13:43:34 UTC, Adam D. Ruppe wrote:
> No, god no. This would break code AGAIN and still not fix the problems, instead introducing new ones!
>
> I think any property proposal that talks about parenthesis in the definition is wrong. With a good definition, the existing type system will handle the parenthesis.
>
> @property int foo() { return 10; }
>
> foo(); // the correct error is "type int is not callable"
>
> This is the key point:
>
> A property is NOT a function as far as user code is concerned. That's just an implementation detail.
>
> As far as user code is concerned, a property IS its return value.
>
>
> If you implement that, leaving all the other rules in the language exactly the same, we'll actually fix some problems without breaking the overwhelming bulk of existing code.
>
>
> Fixing the rest of the problems is then about getting op*Assign to work right.
>
>
>
> Functions not marked @property should NOT change AT ALL from what we have now. I am against removing the existing optional parenthesis rule, and I am against removing the @property decoration.
>
> Fix it this time, don't break it in a different place.

I wholeheartedly agree.

David

On 2013-01-24 14:41, deadalnix wrote:

> 3. @getter is an attribute. A function marked @getter is automatically
> executed : () is added automatically :
>      @getter void funName() {}
>      funName; // function get executed.
>      funName(); // Error, void is not callable.
>
> 4. @getter can be used as UFCS.
>     @getter void funName(T t) {}
>     T t; t.funName; // function gets executed.
>     funName(t); // Error, funName require 1 argument, 0 given.
>
> 5. @setter is an attribute. A setter method can *only* be used in rhs of
> an expression. The assigned value is used as argument.
>     @setter void funName(T t) {}
>     T t; funName = t; // function gets executed.
>     funName(t); // Error, funName must be used in an assign expression.
>
> 6. @setter can as well be used as UFCS :
>     @getter void funName(T t, U u) {}
>     T t; U u; t.funName = u; // function gets executed.
>     t.funName(u); // Error, funName must be used in an assign expression.

What about @property(getter) and @property(setter) instead? Otherwise we need two new built-in attributes.

> 8. method behave as functions :
>      class A { void foo() {} }
>      A a;
>      static assert(is(typeof(a.foo) : void delegate())); // Pass.
>      &a.foo; // deprecated NOOP for compatibility.
>      a.foo(); // call a.foo

The address operator wouldn't be needed to get a delegate for a method anymore?

-- 
/Jacob Carlborg

On Thursday, 24 January 2013 at 13:43:34 UTC, Adam D. Ruppe wrote:
> Functions not marked @property should NOT change AT ALL from what we have now. I am against removing the existing optional parenthesis rule, and I am against removing the @property decoration.
>

I'll be rude, but that is needed.

The whole mess we have today is because of this kind of reasoning (note that I'm only talking about the quoted part, the rest of your post is very good). The process goes as follow.

1. Let's add this special case here, this allow for user X to drop few chars in his source file.

2. How, user Y discovered that this interact in a weird way with feature Z. Let's live with it forever/break code/add this little tweak to feature Z to make it work.

3. If break code isn't chosen, much latter, user K notice that bunch of function of phobos don't take into account some corner cases and go crazy due to the tweak above. Phobos is fixed with adding a big amount of complexity or stay broken as it would mess up too much code. All other libs are broken is that case.

4. Current situation.

On Thursday, 24 January 2013 at 13:56:03 UTC, Jacob Carlborg wrote:
> On 2013-01-24 14:41, deadalnix wrote:
>
>> 3. @getter is an attribute. A function marked @getter is automatically
>> executed : () is added automatically :
>>     @getter void funName() {}
>>     funName; // function get executed.
>>     funName(); // Error, void is not callable.
>>
>> 4. @getter can be used as UFCS.
>>    @getter void funName(T t) {}
>>    T t; t.funName; // function gets executed.
>>    funName(t); // Error, funName require 1 argument, 0 given.
>>
>> 5. @setter is an attribute. A setter method can *only* be used in rhs of
>> an expression. The assigned value is used as argument.
>>    @setter void funName(T t) {}
>>    T t; funName = t; // function gets executed.
>>    funName(t); // Error, funName must be used in an assign expression.
>>
>> 6. @setter can as well be used as UFCS :
>>    @getter void funName(T t, U u) {}
>>    T t; U u; t.funName = u; // function gets executed.
>>    t.funName(u); // Error, funName must be used in an assign expression.
>
> What about @property(getter) and @property(setter) instead? Otherwise we need two new built-in attributes.
>

I don't really care about the syntax. If any new attribute has to be added, they should be defined in some modules instead of builtin.

>> 8. method behave as functions :
>>     class A { void foo() {} }
>>     A a;
>>     static assert(is(typeof(a.foo) : void delegate())); // Pass.
>>     &a.foo; // deprecated NOOP for compatibility.
>>     a.foo(); // call a.foo
>
> The address operator wouldn't be needed to get a delegate for a method anymore?

No, which would eliminate the difference behavior between function as variables and function defined in source code. This is a big step forward for functional style.

On 24 January 2013 13:40, d coder <dlang.coder@gmail.com> wrote:

>
> As much as I want to agree, I also feel this comes as too little, too late
>> to come to this conclusion now.
>>
>
> +1
>
> And therefor we should take out @property ASAP :-)
>
>
Not going to happen.  Effectively what is being proposed here is that we are going to be stuck with the current state of @property for the next 7 years, and no bugs will be fixed on it as its on deprecation.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 2013-01-24 15:04, deadalnix wrote:

> No, which would eliminate the difference behavior between function as
> variables and function defined in source code. This is a big step
> forward for functional style.

Then what do you mean by:

&a.foo; // deprecated NOOP for compatibility.

-- 
/Jacob Carlborg