On Friday, 25 January 2013 at 15:57:16 UTC, deadalnix wrote:
> No adress because :
>  - it would now be impossible to ensure transition using & as NOOP.
>  - this address is useless anyway. That'd be a pointer to a pointer to instructions.
Need to think about it.

> funName is not a getter and don't return a delegate. How a getter behave is explained below. Mixing everything together is the perfect way to create a mess.
Well, but it is were good design vs mess of special cases really shines :) Anyway, in this statement by "function" you mean "non-property function", ye?

> You didn't addressed why @property. Answer you gave to point 5 and 6 make me think you aren't aware of the ambiguities @property causes with UFCS. Please note that :
> [1, 2].front and front = [1, 2] are semantically 100% equivalent.
Not really as I see it.
[1, 2].front // requires signature "@property T front(int[])"
front = [1, 2] // compile error
arr.front = [1, 2] // requires signature "@property void front(T, int[])"

> The above code is rewritten ad funName()(t) .
Ah, _now_ I am starting to get your proposal. And do not like it in that regard.

> Many people here disagree. I tend to be amongst thoses people. This specific case imply no ambiguity, and is similar to other simplification D already make like . dereferencing pointers.
Well, then it is probably best to focus on free-form property semantics and leave argument about optional parens and friends - there were enough of them in this topic ;) I'll push for optional ones to the end but hope at least for the solution where ambiguity is consistently resolved.

On Friday, 25 January 2013 at 16:11:53 UTC, mist wrote:
>> funName is not a getter and don't return a delegate. How a getter behave is explained below. Mixing everything together is the perfect way to create a mess.
> Well, but it is were good design vs mess of special cases really shines :) Anyway, in this statement by "function" you mean "non-property function", ye?
>

That is one case where it matters.

>> You didn't addressed why @property. Answer you gave to point 5 and 6 make me think you aren't aware of the ambiguities @property causes with UFCS. Please note that :
>> [1, 2].front and front = [1, 2] are semantically 100% equivalent.
> Not really as I see it.
> [1, 2].front // requires signature "@property T front(int[])"
> front = [1, 2] // compile error
> arr.front = [1, 2] // requires signature "@property void front(T, int[])"
>

So you DO make a difference between setters and getters.

>> The above code is rewritten ad funName()(t) .
> Ah, _now_ I am starting to get your proposal. And do not like it in that regard.
>

funName(t) is valid if funName returns a delegate. The compiler shouldn't even try to interpret funName(...) as a call of funName.

On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:

One more thing (see also this:
http://www.25hoursaday.com/CsharpVsJava.html#properties)

In order to avoid properties throwing exceptions, maybe is wise
to impose getters and setters to be nothrow.

Why? Because code like this (C#) seems a bit unnatural:

try{

myClock.Hours   = 28;  /* setter throws exception because 28 is
an invalid hour value */
myClock.Minutes = 15;
myClock.Seconds = 39;

}catch(InvalidTimeValueException itve){

/* figure out which field was invalid and report error */

}

On Friday, 25 January 2013 at 00:43:46 UTC, Adam Wilson wrote:
> The problem is that the moment we start talking about @property the optional parens people (colloquially referred to henceforth as "your side") start jumping in and attacking us about how removing optional parens would make your sides lives utter misery.

Well, I'd hope @property could give the compiler enough information to give syntax that matches fields. That hasn't happened yet so I don't see it worth keeping. And if the @property syntax has to be changed from a function I'd consider it a failure too.

That said many that want @property, want optional parens to die, as shown by your side comment that follows.

> (Personally, i'd beg to differ, I work with C# UFCS every, freaking, day. I don't even notice the extra parens any more. But most importantly, the syntax is ambiguous to neither the compiler or myself, I know at a subconscious level what I am looking at.)

I haven't had to deal with reading much other peoples code in D or Ruby, so I don't have much information on the readability challenges from one side or the other, but so far my experience has been that it doesn't matter. And while it is a hot topic, D has had it for a long time and no real evidence it is a big problem has risen. (Only the return a delegate from a function)

On Friday, 25 January 2013 at 16:29:40 UTC, deadalnix wrote:
> So you DO make a difference between setters and getters.
Yes, sure. But I do not need new keywords for that.

> funName(t) is valid if funName returns a delegate. The compiler shouldn't even try to interpret funName(...) as a call of funName.

Yes, I have finally understood how it is intended to work. I just do not like complexity with re-writing funName(t) as funName()(t) and hidden struct creation from function symbols. I cheer any compiling restrictions, but overall type system should be as transparent as possible for normal cases. Like brutal simplicity of my proposal better :)

But it is an interesting approach, thank you for the insight.

On 2013-37-25 17:01, eles <eles@eles.com> wrote:

> On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
>
> One more thing (see also this:
> http://www.25hoursaday.com/CsharpVsJava.html#properties)
>
> In order to avoid properties throwing exceptions, maybe is wise
> to impose getters and setters to be nothrow.
>
> Why? Because code like this (C#) seems a bit unnatural:
>
> try{
>
> myClock.Hours   = 28;  /* setter throws exception because 28 is
> an invalid hour value */
> myClock.Minutes = 15;
> myClock.Seconds = 39;
>
> }catch(InvalidTimeValueException itve){
>
> /* figure out which field was invalid and report error */
>
> }

But setting the hours field to 28 is natural? While I want all
properties to be safe nothrow pure, it is unlikely to be a good
idea to force this upon people.

I'm all for putting it in the style guide, though.

-- 
Simen

On Friday, 25 January 2013 at 16:47:56 UTC, mist wrote:
> On Friday, 25 January 2013 at 16:29:40 UTC, deadalnix wrote:
>> So you DO make a difference between setters and getters.
> Yes, sure. But I do not need new keywords for that.
>

Because you invalidate most legitimate use of a setter.

>> funName(t) is valid if funName returns a delegate. The compiler shouldn't even try to interpret funName(...) as a call of funName.
>
> Yes, I have finally understood how it is intended to work. I just do not like complexity with re-writing funName(t) as funName()(t) and hidden struct creation from function symbols. I cheer any compiling restrictions, but overall type system should be as transparent as possible for normal cases. Like brutal simplicity of my proposal better :)
>

A struct with a function pointer and data already exists in D. This is called a delegate.

> But it is an interesting approach, thank you for the insight.

On Friday, 25 January 2013 at 16:53:43 UTC, deadalnix wrote:
> Because you invalidate most legitimate use of a setter.
Erm.. Whaaat? How this case is legitimate at all? Please elaborate. In example you define a @property for some data type and then try to assign to this property without using any context. It is like calling class method and skipping "this". As I have mentioned in other thread, there are 2 contradictory approaches: either free-form property has semantics of global variable or it has semantics of data member of its first argument. Not both.

> A struct with a function pointer and data already exists in D. This is called a delegate.
And additional hidden implementation complications differ it from all other function types. Rare special case for clearly defined situations. I like it that way. Leave function to be just like good old C function.

On Fri, 25 Jan 2013 05:00:32 -0800, Jacob Carlborg <doob@me.com> wrote:

> On 2013-01-24 23:41, Adam Wilson wrote:
>
>> The one problem with your example is that you haven't defined a way to
>> make the property read-only/write-only like in C#.
>
> @property(get, set) int a;
> @property(get) int b;
> @property(set) int c;
> @property int d; // same as "a"
>

This, for the love of all that is good in the world, a million times this!

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Friday, 25 January 2013 at 16:43:45 UTC, Jesse Phillips wrote:
[...]
> That said many that want @property, want optional parens to die, as shown by your side comment that follows.
>

I think that observation pins the whole debate down, and it's an incredible amount of debate for something that boils down little more than personal taste. We don't even need property-like behavior, it's not that important. Meanwhile really serious problems exist that are not being attended to.

The concept of a property works perfectly fine without explicit @property enforcement (except for perhaps an edge case or two that can be corrected). When I started with D, the TDPL told me that I had to put @property in, and it was actually a relief to discover that I did not have to do that. It's a waste of time, and more than half the time I could not decide if I wanted property-like behavior or not, so the lack of enforcement was a plus for me.

If the default behavior is optional parens plus no @property enforcement, i.e., the current behavior, then for the people who want to change the default behavior need to specify @property and we implement enforcement for those situations. However, for the remaining functions, the property behavior is optional and not enforced, so some means such as the @function proposal will be needed to enforce the traditional c-like function call syntax.

But is there any real need for the extra complications of implementing property and c-style function call enforcement? This is D and there's no law that states that D must behave exactly like C.

I think Walters proposal to shoot @property is perfectly sound. Get rid of it, fix the edge cases, and move on to solving the problems that matter a whole lot more than this one.

If Walter's proposal is not sound, then we need real clear technical reasons why enforcement is required, as opposed to arguments that boil down to personal tastes.

--rt