On Thursday, 24 January 2013 at 14:19:34 UTC, Jacob Carlborg wrote:
> 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.

a.foo is the same as &a.foo . The reason is that &a.foo is used in a lot of code today as it is the only way to perform such action.

As a.foo is not an rvalue, it does not conflict. To achieve the ideally consistent behavior it should be disabled at some point.

On 01/24/13 14:46, mist wrote:
> 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.
> 
> 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.

It's not merely "important"; it is essential.

Those arguing for a "beatiful" UFCS syntax have not considered the consequences. Others see no point in arguing against obvious insanity; which skews the "popularity" numbers further. Just wait a year or so, until someone actually runs into the problems, and watch this discussion reincarnate.

I can offhand think of three or four different ways to have a sane /and/ "beautiful" UFCS syntax, but even just discussing them would be a waste of time...

For example, both of these are doable w/o involving @property nor magic ()-less function calls; the second doesn't even require per-function annotations, at the cost of introducing another operator.

   iota(42, 2_000_000_000).filter!(a=>a&1).map!(to!string).take(10);

   iota(42, 2_000_000_000)->filter!(a=>a&1)->map!(to!string)->take(10);

Having ()-less function calls is just insane; if it isn't obvious to you why,
you just haven't read enough code that (ab)uses them.

IOW, UFCS and @property are not related, except the latter can currently be used as a workaround for missing functionality.

artur

On 1/24/13, Walter Bright <newshound2@digitalmars.com> wrote:
> 2. the:
>     f = g
> rewrite to:
>     f(g)
> only happens if f is a function that only has overloads for () and (one
> argument). No variadics.

This is going to be a problem in API refactoring. if "f" used to be a field but is now turned into a (potentially) expensive function call, the user will have no idea.

Anyway we'll lose track of everything in this thread just like in all the other threads, so I suggest that we:

- Create a new branch in DMD which will only be used to work on @property freely
- Add all test-cases which are affected by this feature
- Work on this branch for some time until we get a solid implementation
- Discuss property enforcement on a casis-by-casis base in the forums,
rather than discussing it wholesome. Special rules should be ok as
long as we properly define them and document them.

And later we'll merge this into master and add some solid bit of documentation to go with it.

Whatever we decide it should be a result of focused work, and not executive decisions due to perceived maintenance costs. We haven't really had a focused effort on properly implementing @property, we've had sporadic pull requests instead.

Am Thu, 24 Jan 2013 14:46:32 +0100
schrieb "mist" <none@none.none>:

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

+1

Just as you and Nick I also like consistent function calls much more.

Properties only make sense if you have consistent function calls, but then they're essential. If we allow optional parenthesis the properties are pretty much useless.

On 01/24/2013 03:34 AM, Walter Bright wrote:
> 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.
>
> 1. Empty parens are optional. If there is an ambiguity with the return
> value taking (), the () go on the return value.
>
> 2. the:
> f = g
> rewrite to:
> f(g)
> only happens if f is a function that only has overloads for () and (one
> argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.

I somehow feel like someone read my article from a couple years ago (http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property) and you implemented the less important part and consciously ignored the more important part.

The section titled "semantic rewriting of properties" is the important one.  Do that.  It removes a source of bugs and gives intuitive behavior to our property-functions (ex: prop++; works in general).

@property is considerably less meaningful: take it or leave it, I certainly won't care.  It's a bikeshed full of personal opinions.

If we had godly hindsight, then we would have made fields non-addressable by default so that people get safe design behavior by default: non-addressable fields can be turned into properties (assuming property rewriting exists) without breaking API, which creates closure for the whole concept.  There would, of course, have to be a way to make it possible to explicitly mark variables as addressable in cases where you need to make pointers to them.  That non-addressability semantic might have helped reference-counting too.  The mistake's made though; we'll probably just have to take that one in the gut.

On 24/01/2013 11:48, Manfred Nowak wrote:
> And on falling flat on that please rethink uglinesses like
> `writefln'. Such mangling of values of parameters into the
> identifiers of procedures might kill maintainability. Or: is
> everyone able to "see" the values hidden in several of such
> appendices coming from several libraries written by several
> coders?
>
> writefln, seefln, grabfln, killfln!
>
> `write( format="%s", someExpression, eol);' is in fact longer than
> `writefln( "%s", someExpression);'

How about:

write!"%s\n" = someExpression;

:-p

Seriously, it would be nice to have a compile-time checked format string for writefln.

Absolutely agree.

I think it's pretty weak to say @property is a monster/failure, and then
look at C# for instance where it's great.
Finish the deed!

Your set of proposed rules are far more complex and non-uniform... what is
the advantage to that complexity?
On 24 Jan 2013 19:15, "Bernard Helyer" <b.helyer@gmail.com> wrote:

> On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
>
>> 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.
>>
>> 1. Empty parens are optional. If there is an ambiguity with the return
>> value taking (), the () go on the return value.
>>
>> 2. the:
>>    f = g
>> rewrite to:
>>    f(g)
>> only happens if f is a function that only has overloads for () and (one
>> argument). No variadics.
>>
>> 3. Parens are required for calling delegates or function pointers.
>>
>> 4. No more @property.
>>
>
> This is lazy design, plain and simple. You say it's turned into
> a monster, but @property, at its core, is simpler than the heuristics
> you've demonstrated here. To my mind, @property, properly implemented
> is simple:
>
> @property functions may be called with no parens or with assignment as the singular argument. Non @property functions may not.
>
> There. No complications. The only complications come from D's history. And then you want to turn it back? This seems a terrible idea -- the deed is done, pull the trigger. Make @property mandatory for property functions.
>
>
> -Bernard.
>

On 1/24/13 3:57 AM, Jacob Carlborg wrote:
> On 2013-01-24 09:34, Walter Bright wrote:
>> 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.
>>
>> 1. Empty parens are optional. If there is an ambiguity with the return
>> value taking (), the () go on the return value.
>>
>> 2. the:
>> f = g
>> rewrite to:
>> f(g)
>> only happens if f is a function that only has overloads for () and (one
>> argument). No variadics.
>
> What do you mean by: "overloads for ()"?

That means there must be two overloads of f exactly:

T f();
f(T);

>> 3. Parens are required for calling delegates or function pointers.
>>
>> 4. No more @property.
>
> So:
>
> void delegate () foo ();
>
> foo() // would call the delegate ?

Yes.

a = foo; // fetch the delegate
b = foo(); // fetch and invoke the delegate


Andrei

On 1/24/13 4:03 AM, anonymous wrote:
> On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
>> 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.
> [...]
>> 4. No more @property.
>
> You went half the way and now you're tired. Going back will be just as
> painful as going all the way.
> I say, keep @property and fix it.

This is a fix.

Andrei

On Thursday, 24 January 2013 at 16:29:07 UTC, Andrei Alexandrescu wrote:
> Yes.
>
> a = foo; // fetch the delegate
> b = foo(); // fetch and invoke the delegate
>

I generic code, bugs I predict !