On Thursday, 24 January 2013 at 09:03:45 UTC, 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.

+1

Walter Bright wrote:

> I want to get rid of @property. It's an eyesore.

Yes!

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);'

Really?

-manfred

I am probably I minority here but I liked the most strict -property version and it made a lot of sense to me. Rationale is simple:
some().ufcs().chaining(); - this is just a minor syntax inconvenience
anything; - this drives me crazy, there is no way to understand if this a no-op statement variable of function call with some side-effect
I'd really like to have all function types to be obliged to use () and use property syntax only to those of property semantics (no side-effect variable getter/setter)

But looking at other comments this does not seem popular :( Well, I can only hope for something simple and non-revolutionary then.

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.

Bernard Helyer:

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

Sounds OK.

Instead of adding a -property, why wasn't this done since the beginning? (The right switch to add was -noproperty, to disable the feature, because most people do not use switches).

Bye,
bearophile

On 2013-01-24 13:35, bearophile wrote:

> Instead of adding a -property, why wasn't this done since the beginning?

It would break tons of code.

-- 
/Jacob Carlborg

Jacob Carlborg:

> It would break tons of code.

How much work does it take to change that makes and compilation scripts to compile that code using a "-noproperty" switch?

I think this silly fear of breaking user code was one of the main causes of the failure of @property in the first place. If you introduce a new feature, then you need to introduce it cleanly since the beginning, otherwise you will make a mess. So future D feature must be introduced in a much more clean way in future, or not introduced at all.

Bye,
bearophile

On Thursday, 24 January 2013 at 12:53:45 UTC, Jacob Carlborg wrote:
> On 2013-01-24 13:35, bearophile wrote:
>
>> Instead of adding a -property, why wasn't this done since the beginning?
>
> It would break tons of code.

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.

On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
> 4. No more @property.


Looks fine for me. D2 code is better but sometimes so much
noisier than D1. There, I said it.

mist:

> but it was a horrible design error in first place
> which needs to be fixed.

Don't forget that our discussions in this thread are mostly academic :-)

Bye,
bearophile