On Thu, 24 Jan 2013 00:34:42 -0800, Walter Bright <newshound2@digitalmars.com> 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 don't see what is so bloody difficult about this. C# has very good very clear guidelines and syntax enforcement. I think it's a case of D trying to be TO flexible.

In C#:
Function Calls have Parens. Period.
Property Calls do NOT have Parens. Period.
It's quick, clean, and easy to parse.
C# has it's own issue with verbosity around declaration of properties, but for a property consumer the rules are trivial. That's the whole point of properties.
Also note, that C# has the 'property' keyword to enforce proper syntax.

In D:
Optional parens for everyone!
Parsing nightmare for all!

I also want to reiterate a point I've seen on this thread. Parens on properties is a very C programmer thing. What is the net effect of forcing properties to have parens? I have to type two more shift-characters to satisfy the compiler because we couldn't be arsed to get the current implementation right. Ehm. That's not how you make a case to newbie... Banish that idea, permanently!

Let's consider what a property really is. It's a data encapsulation tool. They allow us to expose object internal data in a safe way. Nuking the idea is a step backwards.

While I get that C++ users would immediately be comfortable with the ambiguities of not having a distinct property mechanism, you're going to have to explain to all the C#/Java users the as long as you create the correct functions the compiler will automagically figure out it's a property.

And consider that in not all cases do I want int GetMyData() { } to be callable without parens as you are suggesting here. Although I provide no demo implementation, imagine that this is a non-trivial function that modifies other data in the object. (Although properties can do this in C#, it runs against guidelines.) Now some innocent programmer calls my function as a property not realizing what is really going on and BOOM! He just wrote himself a bug. And yes, i've written code like this before. And before the academics pile on me for it. My job is to write code that gets the job done, being academically correct is for when all other requirements have been satisfied. In the real world, we don't have the luxury of spending a day to make our code ideal.

One of the principles of encapsulated data is that accessing the data has zero side-effects. This change makes what is happening ambiguous to the user of the property/function. Ambiguity is bad and will NOT solve our problems.

My vote: Fix @property. Dropping it will create even more problems and not likely fix many of the current ones. You never solve problems by making the code more ambiguous.

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

On 1/24/2013 5:41 AM, deadalnix wrote:
> For regular functions :
> 1. funName is the function itself :
>    void funName() {}
>    static assert(is(typeof(funName) == void function())); // Pass.
>    funName has no address, it is equivalent to enum function void() funName = {};
>    &funName become a NOOP and is deprecated, for compatibility reasons. It is
> not ambiguous as funName has no address anyway.

Dang, I hadn't thought of the typeof(funName) issue.

On Thursday, 24 January 2013 at 20:20:42 UTC, Adam Wilson wrote:
> Let's consider what a property really is. It's a data encapsulation tool. They allow us to expose object internal data in a safe way. Nuking the idea is a step backwards.

This, this and this again. Reading this thread I sometimes get the feeling that part of programmers treat property as a nice way to save 2 extra symbols. Or probably to play with verb/noun meaning. It has different goals from both of those.

On 1/24/2013 12:23 PM, Walter Bright wrote:
> On 1/24/2013 5:41 AM, deadalnix wrote:
>> For regular functions :
>> 1. funName is the function itself :
>>    void funName() {}
>>    static assert(is(typeof(funName) == void function())); // Pass.
>>    funName has no address, it is equivalent to enum function void() funName = {};
>>    &funName become a NOOP and is deprecated, for compatibility reasons. It is
>> not ambiguous as funName has no address anyway.
>
> Dang, I hadn't thought of the typeof(funName) issue.
>

On further thought, if funName is a property, then typeof(funName) should give the return type of the property, not the 'function' type.

On Thursday, 24 January 2013 at 20:26:50 UTC, mist wrote:
> On Thursday, 24 January 2013 at 20:20:42 UTC, Adam Wilson wrote:

I think the widest spread use case of a property is:

you start with a variable as memeber of a class, you write a lot
of assignment code, then you decide that you need to do some more
extensive processing instead of simple assignment, and all that
without breaking existing code.

so, you transform the variable into a property.

of course, it could happen the other way around (converting a
function into a property/variable).

On Thu, 24 Jan 2013 12:51:32 -0500
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/24/13 7:13 AM, Bernard Helyer 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.
> 
> No. The complications come from the fact that (a) nobody could agree what should be a @property and what shouldn't;

No, you merely came up with *some* specific cherry-picked examples that
sparked *some* debate (with most of the disagreing coming from
you).

Stop mischaracterizing what really happened:

It's well known that you never liked or fully understood the idea of properties in the first place, even by your own admission. So you made a post some number of months back attempting to drum up dissent for properties by stirring up the notion, which just about only you believed, that the choice between property and function is inherently unclear.

So to "prove" this you cherry-picked some grey area cases (gee,
occasional grey judgement calls when mapping ideas into code,
yea, there's something that doesn't happen without @property). You
succeeded ONLY in proving that there exist *some* cases which may be
grey-area judgement calls (again, big surprise, occasional grey-area
judgement calls when writing code). But then you - and ONLY you - took
this proof that "*some* cases exist" and declared "Look, look, everyone!
I proved that *nobody* can agree on property vs function *in general*!
QED!"

And you continue declaring that non-sequitur to this day.

> (b) @property adds
> noise for everybody for the sake of a corner case (functions
> returning delegates);

The only reason functions returning delegates have *ever* been an any issue at all is *purely* because of the insistence on optional parens on arbitrary function calls.


> (c) the @property discipline failed to align
> itself in any way with better code quality.
> 

Ok, now *that* argument is just pure unadulterated bullshit. In languages like C# that have *real* and *completed* property support, yes, the general consensus IS that they DO definitely help. Please take your blinders off, and you'll see that.

But then there's D, which adds a half-baked and
incompletely-implemented "properties" - and did so *reluctantly* I
should add. Leaves it in that broken state untouched for a year or two.
And now here you are effectively saying "This
half-designed/half-implemented feature is causing dissent and not
helping people, therefore the problem must be the whole idea of
properties and couldn't possibly be due to our broken version of
them" (for the record - I *do* find D's current properties helpful,
just not as helpful as they would be if they weren't broken).

On Thursday, January 24, 2013 00:34:42 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.

Another issue to consider is enhancements such as

http://d.puremagic.com/issues/show_bug.cgi?id=8006

As a property function is supposed to be an abstraction for a variable, and you really should be able to swap out property functions and public variables without breaking code, things like

foo.prop += 5;

and

++foo.prop;

should work. Unfortunately, D's current property implementation is poor enough that that code doesn't currently, but that can be fixed in a backwards- compatible-manner.

But implementing something like that becomes more problematic without explicit properties (potentially even dangerous, depending on what ends up happening with those sorts of expressions with non-@property functions which are called without parens). Maybe it could be done, but it seems to me that it's the sort of thing that should be controlled. We don't want lots of voodoo happening with functions called without parens, as we risk getting some nasty bugs when using functions that weren't really meant to be properties. But we _do_ want some of that voodoo with functions that are designed to be properties.

So, I really think that we need to have explicit properties, even if we allow paran-less function calls in some other cases.

But honestly, I wish that we'd just gone with something closer to what C# did with properties from the get-go.

- Jonathan M Davis

On Thursday, 24 January 2013 at 20:44:33 UTC, eles wrote:
> On Thursday, 24 January 2013 at 20:26:50 UTC, mist wrote:
>> On Thursday, 24 January 2013 at 20:20:42 UTC, Adam Wilson wrote:
>
> I think the widest spread use case of a property is:
>
> you start with a variable as memeber of a class, you write a lot
> of assignment code, then you decide that you need to do some more
> extensive processing instead of simple assignment, and all that
> without breaking existing code.
>
> so, you transform the variable into a property.
>
> of course, it could happen the other way around (converting a
> function into a property/variable).

It is a wrong use case for a property. Necessity to change data assignment/access to call of function with side-effect is design error and should be fixed with programmers experience, not property hacks.

On 1/24/2013 5:42 AM, Jacob Carlborg wrote:
> I agree with you but Walter is very afraid of breaking code.

The history of what happens when D code breaks because of language changes is not a happy one.

On 1/24/13, Walter Bright <newshound2@digitalmars.com> wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.

It is super-ironic that you want to simply pull-out and destroy a feature because it wasn't properly defined or implemented, yet you single-handedly introduced UDAs into the language with its own syntax without any prior approval of the community.

Will we be making a "UDAs - take it behind the woodshed and shoot it?" thread a year from now?