www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - property - take it behind the woodshed and shoot it?

reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 24 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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 ()"?
 3. Parens are required for calling delegates or function pointers.

 4. No more  property.

So: void delegate () foo (); foo() // would call the delegate ? -- /Jacob Carlborg
Jan 24 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/24/2013 12:57 AM, Jacob Carlborg wrote:
 only happens if f is a function that only has overloads for () and (one
 argument). No variadics.

What do you mean by: "overloads for ()"?

I mean there are no f(...) and f(U,T) overloads.
 3. Parens are required for calling delegates or function pointers.

 4. No more  property.

So: void delegate () foo (); foo() // would call the delegate ?

Yes.
Jan 24 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 24 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 11:43 AM, deadalnix wrote:
 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 !

I agree it's something one must mind. Andrei
Jan 24 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 12:15 PM, Peter Alexander wrote:
 On Thursday, 24 January 2013 at 16:29:07 UTC, Andrei Alexandrescu wrote:
 On 1/24/13 3:57 AM, Jacob Carlborg wrote:
 void delegate () foo ();

 foo() // would call the delegate ?

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

How about generic code? void callFunc(alias f, Args...)(Args args) { f(args); } void delegate() foo(); void delegate(int) bar(int x); callFunc!foo(); // calls delegate? callFunc!bar(0); // calls bar? Seems like a recipe for disaster.

Agreed. This is a good litmus test. One option we had in mind was to still keep property for disambiguating such cases. Andrei
Jan 24 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 1:37 PM, Adam D. Ruppe wrote:
 Thinking about it, this isn't quite a full circle. It does improve a bit.

Yes, I was about to write an email to destroy :o).
 If we aren't going dip21, how about:

 ===

 Everything stays the way it is now, except:

 * if a  property is called with parens, they always apply to the return
 value

 * -property hopefully dies.

 ===


 I don't really like it, it leaves a number of problems behind... but
 that would be an improvement on the status quo. I don't hate it.

Interesting, thanks. Andrei
Jan 24 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/24/2013 10:17 AM, Andrei Alexandrescu wrote:
 On 1/24/13 12:15 PM, Peter Alexander wrote:
 On Thursday, 24 January 2013 at 16:29:07 UTC, Andrei Alexandrescu wrote:
 On 1/24/13 3:57 AM, Jacob Carlborg wrote:
 void delegate () foo ();

 foo() // would call the delegate ?

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

How about generic code? void callFunc(alias f, Args...)(Args args) { f(args); } void delegate() foo(); void delegate(int) bar(int x); callFunc!foo(); // calls delegate? callFunc!bar(0); // calls bar? Seems like a recipe for disaster.

Agreed. This is a good litmus test. One option we had in mind was to still keep property for disambiguating such cases.

Another option is f(args) always requires parens, even if args expands to 0 args.
Jan 24 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/24/2013 8:29 AM, Andrei Alexandrescu wrote:
 What do you mean by: "overloads for ()"?

That means there must be two overloads of f exactly: T f(); f(T);

There could also be f(U), f(V), etc., just that the are all 0 or 1 arg.
Jan 24 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/24/2013 8:43 AM, deadalnix wrote:
 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 !

I would also count: f(some tuple) as requiring () even if "some tuple" expands to zero arguments. This should resolve issues with generic code.
Jan 24 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 17:29, Andrei Alexandrescu wrote:

 That means there must be two overloads of f exactly:

 T f();
 f(T);

That's somewhat problematic since it won't allow chaining assignments: auto i = f = 3; We need to either allow: T f (); T f (T); Or implement some form of rewrite: f = 3; // calls setter auto i = f; // calls getter This is the preferred solution. -- /Jacob Carlborg
Jan 25 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 10:16, deadalnix wrote:

 Assignation is right associative, so it is equivalent to :
 auto i = (f = 3);

 The setter is called.

That's what I'm saying, the setter needs to be able to return something and not just void. -- /Jacob Carlborg
Jan 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 14:26, mist wrote:

 Hm, shouldn't it be processed like that:
 1) evaluate "f = 3", setter called
 2) evaluate "(f = 3)" -> evaluate "f" -> getter called
 3) evaluate "auto i = ", setter called
 ?

Yes, but why would a setter be called at step 3? -- /Jacob Carlborg
Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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 !
Jan 24 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 24 January 2013 at 16:29:07 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 3:57 AM, Jacob Carlborg wrote:
 void delegate () foo ();

 foo() // would call the delegate ?

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

How about generic code? void callFunc(alias f, Args...)(Args args) { f(args); } void delegate() foo(); void delegate(int) bar(int x); callFunc!foo(); // calls delegate? callFunc!bar(0); // calls bar? Seems like a recipe for disaster.
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 18:17:48 UTC, Andrei Alexandrescu 
wrote:
 Agreed. This is a good litmus test. One option we had in mind 
 was to still keep  property for disambiguating such cases.

It seems we've gone full circle. Tends to happen when you try to fix 3 wrong turns with a 4th wrong turn :)
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
Thinking about it, this isn't quite a full circle. It does 
improve a bit.

If we aren't going dip21, how about:

===

Everything stays the way it is now, except:

* if a  property is called with parens, they always apply to the 
return value

* -property hopefully dies.

===


I don't really like it, it leaves a number of problems behind... 
but that would be an improvement on the status quo. I don't hate 
it.


So:

alias void delegate() Callable;

Callable nonprop();
 property Callable prop();

Callable returned = nonprop; // ok, the parens are optional
Callable returned = nonprop(); // ok, nonprop() just calls 
nonprop like any other function

Callable returned = prop; // ok, no parens still calls, just like 
before
Callable returned = prop(); // NOT GOOD: the () applies to the 
Callable (which returns void), not prop, because prop has 
 property

BTW
nonprop()(); // calls the Callable (this expression returns void)
prop()(); // nonsense (prop() returns void, which is not callable)

---

int nonprop();
 property int prop();

int returned = nonprop; // fine, optional parens
int returned = nonprop(); // fine

int returned = prop; // fine, we just call prop
int returned = prop(); // NO GOOD: the () always applies to the 
return value, which in this case is int, which is not callable
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 09:12:47 UTC, Jacob Carlborg wrote:
 On 2013-01-24 17:29, Andrei Alexandrescu wrote:

 That means there must be two overloads of f exactly:

 T f();
 f(T);

That's somewhat problematic since it won't allow chaining assignments: auto i = f = 3; We need to either allow: T f (); T f (T); Or implement some form of rewrite: f = 3; // calls setter auto i = f; // calls getter This is the preferred solution.

Assignation is right associative, so it is equivalent to : auto i = (f = 3); The setter is called.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 13:18:47 UTC, Jacob Carlborg wrote:
 On 2013-01-25 10:16, deadalnix wrote:

 Assignation is right associative, so it is equivalent to :
 auto i = (f = 3);

 The setter is called.

That's what I'm saying, the setter needs to be able to return something and not just void.

Hm, shouldn't it be processed like that: 1) evaluate "f = 3", setter called 2) evaluate "(f = 3)" -> evaluate "f" -> getter called 3) evaluate "auto i = ", setter called ?
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 13:52:37 UTC, Jacob Carlborg wrote:
 On 2013-01-25 14:26, mist wrote:

 Hm, shouldn't it be processed like that:
 1) evaluate "f = 3", setter called
 2) evaluate "(f = 3)" -> evaluate "f" -> getter called
 3) evaluate "auto i = ", setter called
 ?

Yes, but why would a setter be called at step 3?

Was thinking about i setter, did not pay attention it is actually a new declaration :) Never mind.
Jan 25 2013
prev sibling next sibling parent "sclytrack" <sclytrack shorter.com> writes:
On Thursday, 24 January 2013 at 18:38:00 UTC, Adam D. Ruppe wrote:
 Thinking about it, this isn't quite a full circle. It does 
 improve a bit.

 If we aren't going dip21, how about:

 ===

 Everything stays the way it is now, except:

 * if a  property is called with parens, they always apply to 
 the return value

 * -property hopefully dies.

 ===

If this means keeping the writeln = ""; then vote++. I've got no issues with the property syntax for methods. I actually want them. Why should properties only get the shorter syntax?
 I don't really like it, it leaves a number of problems 
 behind... but that would be an improvement on the status quo. I 
 don't hate it.


 So:

 alias void delegate() Callable;

 Callable nonprop();
  property Callable prop();

 Callable returned = nonprop; // ok, the parens are optional
 Callable returned = nonprop(); // ok, nonprop() just calls 
 nonprop like any other function

 Callable returned = prop; // ok, no parens still calls, just 
 like before
 Callable returned = prop(); // NOT GOOD: the () applies to the 
 Callable (which returns void), not prop, because prop has 
  property

 BTW
 nonprop()(); // calls the Callable (this expression returns 
 void)
 prop()(); // nonsense (prop() returns void, which is not 
 callable)

 ---

 int nonprop();
  property int prop();

 int returned = nonprop; // fine, optional parens
 int returned = nonprop(); // fine

 int returned = prop; // fine, we just call prop
 int returned = prop(); // NO GOOD: the () always applies to the 
 return value, which in this case is int, which is not callable

Jan 27 2013
prev sibling parent "anonymous" <anonymous shorter.com> writes:
On Sunday, 27 January 2013 at 10:30:41 UTC, sclytrack wrote:
 On Thursday, 24 January 2013 at 18:38:00 UTC, Adam D. Ruppe 
 wrote:
 Thinking about it, this isn't quite a full circle. It does 
 improve a bit.

 If we aren't going dip21, how about:

 ===

 Everything stays the way it is now, except:

 * if a  property is called with parens, they always apply to 
 the return value

 * -property hopefully dies.

 ===

If this means keeping the writeln = ""; then vote++. I've got no issues with the property syntax for methods. I actually want them. Why should properties only get the shorter syntax?

Also since you can't overload property opDispatch and opDispatch at the same time without knowing all the property names or method names at compile time you can use the opDispatch for everything if the methods have a property like syntax.
Jan 27 2013
prev sibling next sibling parent reply "anonymous" <anonymous example.com> writes:
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.
Jan 24 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 24 2013
prev sibling next sibling parent reply "Don" <don nospam.com> writes:
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.

I agree, the cure seems to be ten times worse than the disease. It's consumed far more resources than it is worth. In my experience one of the main reasons that projects fail, is that nobody had the courage and humility to say, "this idea is a failure, we need to throw it away and do something completely different".
 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.

An example would make this easier to understand.
 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.

Jan 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/24/2013 1:11 AM, Don wrote:
 1. Empty parens are optional. If there is an ambiguity with the return value
 taking (), the () go on the return value.

An example would make this easier to understand.

Jacob's should do.
Jan 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/24/2013 2:21 AM, Minas Mina wrote:
 We are going to see code like this:
 printSomeStuff; // i think that's ugly.

Eeeyup. As for it being 'ugly', yes, it is a bit unsettling to us old time C programmers, but I think we can get used to it in short order. You can still add the () if you prefer.
 I suggested make parentheses optional only for UFC syntax.

The simpler the rules are, the more likely they are to work.
 Also isn't it possible to allow  property for functions that belong in a
 class/struct only?

I want to get rid of property. It's an eyesore.
Jan 24 2013
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Jan 24 2013
parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
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.
Jan 24 2013
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Nick Treleaven wrote:

 write!"%s\n" = someExpression;

Iff at all I prefer `write!someExpression= "%s\n";' Seriously, checking validity at execution time causes another sort of hiccoughs that should not be part of a language intended for large scale coding. -manfred
Jan 24 2013
parent Manfred Nowak <svv1999 hotmail.com> writes:
Simen Kjaeraas wrote:

 Seriously


 whereas yours does not

To me it is a syntactical change only. Where can I find the semantical change? And ... did you overlook the "seriously". -manfred
Jan 25 2013
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Philippe Sigaud wrote:

 cwritefln!"For sample

Cough! `cfln' would eliminate the five letters `write'. For which purpose are they needed? Seriously, without some guarentee that `!"' starts a compile time checked string---and a defined metalanguage for describing compile time checking of compile time checked strings---close to every coding project will become an unmaintanable mess of DSL implementations "on the fly". The code you supplied on pages 170 to 171 is a good example for this forsight: please declare how much time an average member of an intended group of maintenance coders will need to grab the content of your idea. And of course declare the minimal skills all members of this group must have. -manfred
Jan 24 2013
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Philippe Sigaud wrote:

 Such hate...

 please give us your own code and preferred solution
 to compile-time formatting string checking.

general problem to incorporate expectable many DSL's into one big source base, as D is intended to serve large scale coding. I am sure that your "stab at it" does not show any intent to approach the general problem. -manfred
Jan 25 2013
next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/26/13 08:50, Philippe Sigaud wrote:
 please give us your own code and preferred solution
 to compile-time formatting string checking.

general problem to incorporate expectable many DSL's into one big source base, as D is intended to serve large scale coding.

And what's the solution, for you? Using strings as DSL is somewhat common in D.

I think his point was that inventing a custom dsl for everything does not scale. And he's of course right. Having one, or at most a few, common "std" dsls, plus ability do define custom ones is enough. But the "std" ones must be able to handle 95%+ of cases. So that everyone does not need to learn a set of custom per-site and/or per-project dsls. BTW, the std compile-time string formatting "dsl" is not only checkable, but can relatively easily be parsed at CT; the compiler will then do the rest. So there's really no point in using such a CT checker - if the string can be checked then it can also be handled directly, skipping any runtime parsing overhead completely.
 As for DSL, well, I have a parser generator project here
 (https://github.com/PhilippeSigaud/Pegged), and I recently added the
 capacity to add new rules to a grammar at runtime and modify the
 resulting parse tree. I also used the existent, but unused macro
 keyword in D to get source code that can define its own subsequent
 grammar and parse tree transformations.
 Oh, and grammars can call one another, so adding a new sublanguage to
 a parent language is doable (I use this from time to time). I still
 have weeks fo work on this to have it reach the level I want, but I
 did not hit any wall up to now.
 So adding clean-looking DSL can be done in D, I think.

Yes, this is possible, and desirable, to avoid "polluting" the main language with certain "features". However it's likely not enough, as there are aspects of D which make pure macro/dsl solutions not as simple as they could be (consider static-foreach). Your inline, parse-time, grammar extensions only work when the parser runs at CT, so the performance issues remain, right? Still, sounds interesting; and could be enough to explore the trickier cases and identify further problems. Must find time to play with it. Is that feature already in the repo? artur
Jan 26 2013
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/26/13 11:46, Artur Skawina wrote:
 identify further problems. Must find time to play with it. Is that
 feature already in the repo?

Found it. Unfortunately the old compiler here can't handle newer D features and I can't really upgrade right now, so playing with pegged will have to wait. artur
Jan 26 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/13 2:50 AM, Philippe Sigaud wrote:
 As for DSL, well, I have a parser generator project here
 (https://github.com/PhilippeSigaud/Pegged), and I recently added the
 capacity to add new rules to a grammar at runtime and modify the
 resulting parse tree. I also used the existent, but unused macro
 keyword in D to get source code that can define its own subsequent
 grammar and parse tree transformations.
 Oh, and grammars can call one another, so adding a new sublanguage to
 a parent language is doable (I use this from time to time). I still
 have weeks fo work on this to have it reach the level I want, but I
 did not hit any wall up to now.
 So adding clean-looking DSL can be done in D, I think.

 I am sure that your "stab at it" does not show any intent to
 approach the general problem.

No, indeed :) Since it's a recurring question here, I just showed it could be done. It's also a simple example of what can be done with D meta-programming capacities.

Looking forward to your talk? :o) Andrei
Jan 26 2013
prev sibling parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 24/01/2013 17:04, Philippe Sigaud wrote:
 On Thu, Jan 24, 2013 at 4:53 PM, Nick Treleaven
 <ntrel-public yahoo.co.uk> wrote:

 write!"%s\n" = someExpression;

 :-p

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

I made a stab at it in a template tutorial that can be found on github: https://github.com/PhilippeSigaud/D-templates-tutorial You can grab the pdf, it's on section 5.11, p. 168 (Statically-Checked Writeln) Use example: cwritefln!"For sample #%d, the results are (%s, %f)"( 0, "foo", 3.14);

Yes, I wish that was in Phobos ;-) In fact, couldn't cwritefln just be a template overload of writefln? The string value parameter may be enough to distinguish it from the runtime version.
Jan 25 2013
prev sibling next sibling parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
f = g; where it means f(g) is really ugly. I wouldn't like to see 
this.

Also:

void printSomeStuff()
{
   //...
}

We are going to see code like this:
printSomeStuff; // i think that's ugly.

I suggested make parentheses optional only for UFC syntax.
Also isn't it possible to allow  property for functions that 
belong in a class/struct only?
Jan 24 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 24 January 2013 at 10:22:00 UTC, Minas Mina wrote:
 f = g; where it means f(g) is really ugly. I wouldn't like to 
 see this.

 Also:

 void printSomeStuff()
 {
   //...
 }

 We are going to see code like this:
 printSomeStuff; // i think that's ugly.

 I suggested make parentheses optional only for UFC syntax.
 Also isn't it possible to allow  property for functions that 
 belong in a class/struct only?

property also makes sense for global functions that need to emulate a run-time initialized static variable.
Jan 24 2013
prev sibling next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:

 4. No more  property.

yippee! -manfred
Jan 24 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
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
Jan 24 2013
prev sibling next sibling parent reply "mist" <none none.none> writes:
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.
Jan 24 2013
next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
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
Jan 24 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 9:47 AM, Artur Skawina wrote:
 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.

You see, this is the kind of argument that I find very damaging to the conversation. It lacks any shred of material evidence, evokes emotion, manipulates the reader's opinion (framing them into incompetent/inexperienced if they disagree), and implies an appeal to authority. Please don't do that anymore. Thanks, Andrei
Jan 24 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 2:03 PM, Artur Skawina wrote:
 On 01/24/13 19:05, Andrei Alexandrescu wrote:
 On 1/24/13 9:47 AM, Artur Skawina wrote:
 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.

You see, this is the kind of argument that I find very damaging to the conversation. It lacks any shred of material evidence, evokes emotion, manipulates the reader's opinion (framing them into incompetent/inexperienced if they disagree), and implies an appeal to authority. Please don't do that anymore.

You're more than welcome to produce counterevidence, or ignore the arguments, for whatever reasons. Ad hominems won't work, not only because I don't take this personally, but because I'm probably the person most willing/likely to discuss any relevant issues around here (I wish there was more like us (ie me)).

Good quality discussion is always welcome. I have specifically opposed a specific rhetoric, not a person, so "ad hominem" is inappropriate here.
 Trying to make arguments you don't like go away and silencing the messenger
 is your MO.

Now that's what's called "ad hominem".
 Please don't do that anymore.

I will always protest the rhetoric mentioned, sorry.
 Not because I ask you to, but because it
 does harm the language, and the "community".  Trying to at least understand the
 other point of view and reflecting a bit can be very enlightening. Who knows,
you
 might even learn something new.

Sarcasm is always appreciated :o). On a serious note, it's a bit assuming to conclude that disagreeing with something must be caused by not understanding it. This is not rocket science. The points involved are understood. That doesn't entail agreement.
 Having said that, I'll elaborate on the sentence you quoted above. See for
example
 Timon's code [1] here: http://dpaste.dzfl.pl/baa538af . Spot the recursion in
the
 tree-walker.

How about this: insert the parens and then demonstrate how the bug is easier to spot. Wasn't any easier for me. Andrei
Jan 24 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 09:13 PM, Andrei Alexandrescu wrote:
 ...
 Having said that, I'll elaborate on the sentence you quoted above. See
 for example
 Timon's code [1] here: http://dpaste.dzfl.pl/baa538af . Spot the
 recursion in the
 tree-walker.

How about this: insert the parens and then demonstrate how the bug is easier to spot. Wasn't any easier for me.

There is no bug.
Jan 24 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/13 2:12 AM, Artur Skawina wrote:
 On 01/24/13 21:13, Andrei Alexandrescu wrote:
 On 1/24/13 2:03 PM, Artur Skawina wrote:
 Trying to make arguments you don't like go away and silencing the messenger
 is your MO.

Now that's what's called "ad hominem".

No, it's not - it's just stating the facts; this was not the first such incident.

Of course it is. The definition is simple enough, e.g. from Wikipedia: An ad hominem (Latin for "to the man"), short for argumentum ad hominem, is an argument made personally against an opponent instead of against their argument.
 Having said that, I'll elaborate on the sentence you quoted above. See for
example
 Timon's code [1] here: http://dpaste.dzfl.pl/baa538af . Spot the recursion in
the
 tree-walker.

How about this: insert the parens and then demonstrate how the bug is easier to spot. Wasn't any easier for me.

Bug? In Timon's code? Impossible. :) No, this is just about syntax. Some functions are not suitable for calling w/o '()', and the choice needs to stay with the callee. But the distinction is "sane/insane" for a reason - there's judgment, taste and common sense involved. Trusting every programmer to get it right won't work, unfortunately.

I'd say "sane/insane" is pushing it. Andrei
Jan 24 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/13 5:56 AM, Artur Skawina wrote:
 On 01/25/13 08:39, Andrei Alexandrescu wrote:
 On 1/25/13 2:12 AM, Artur Skawina wrote:
 On 01/24/13 21:13, Andrei Alexandrescu wrote:
 On 1/24/13 2:03 PM, Artur Skawina wrote:
 Trying to make arguments you don't like go away and silencing the messenger
 is your MO.

Now that's what's called "ad hominem".

No, it's not - it's just stating the facts; this was not the first such incident.

Of course it is. The definition is simple enough, e.g. from Wikipedia: An ad hominem (Latin for "to the man"), short for argumentum ad hominem, is an argument made personally against an opponent instead of against their argument.

Hmm, I can see how you could view this as an ad hominem, given that definition,

How can that be seen as anything else? What definition do you have? You made a mistake under the heat of the argument. We all do. Don't try to explain how actually you didn't. The right course is to casually apologize and move on.
 but it's not meant to be one and actually isn't - it has no bearing on
 the  property nor ()-less calls issues; this is just about the process.

 Remember how you originally replied to my message, after removing everything
 but one sentence, which was clearly both a summary of my subjective position
 and deliberately phrased in a way to encourage at least some consideration wrt
 $subject by others making a decision.

I kept the sentence that I had a reply for. The rest I understood and agreed with. Andrei
Jan 25 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/25/13 15:28, Andrei Alexandrescu wrote:
 On 1/25/13 5:56 AM, Artur Skawina wrote:
 On 01/25/13 08:39, Andrei Alexandrescu wrote:
 On 1/25/13 2:12 AM, Artur Skawina wrote:
 On 01/24/13 21:13, Andrei Alexandrescu wrote:
 On 1/24/13 2:03 PM, Artur Skawina wrote:
 Trying to make arguments you don't like go away and silencing the messenger
 is your MO.

Now that's what's called "ad hominem".

No, it's not - it's just stating the facts; this was not the first such incident.

Of course it is. The definition is simple enough, e.g. from Wikipedia: An ad hominem (Latin for "to the man"), short for argumentum ad hominem, is an argument made personally against an opponent instead of against their argument.

Hmm, I can see how you could view this as an ad hominem, given that definition,

How can that be seen as anything else? What definition do you have? You made a mistake under the heat of the argument. We all do. Don't try to explain how actually you didn't. The right course is to casually apologize and move on.

No. Please don't try to reinterpret what I said, this is the second time you did this. But, like i said, I can see that you view it like that. Fact is that that comment had absolutely nothing to do with the argument itself - I was only replying to your response, which was unacceptable. So, yes, I am talking about what you did, but that does not automatically mean it's an ad hominem, otherwise any critical comment about how the conversation is handled by the other side would be. I did make that comment too generic, and for that I'll apologize - I really should have said that /it happens/, and not used a figure of speech that can reasonably be misunderstood. I should have reread and caught that, I'm sorry. I'm still saying that these types of responses, when uncalled for (at least I didn't say 'in a well defined language..."), but caused only by your dislike of the argument or form thereof, are inappropriate.
 I kept the sentence that I had a reply for. The rest I understood and agreed
with.

It contained examples showing how all '()' could be omitted within ufcs chains, except the last pair. That would be a reasonable compromise, make code concise and unambiguous to read, but I guess you don't agree that doing it like that would be enough. artur
Jan 25 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/25/13 08:39, Andrei Alexandrescu wrote:
 On 1/25/13 2:12 AM, Artur Skawina wrote:
 On 01/24/13 21:13, Andrei Alexandrescu wrote:
 On 1/24/13 2:03 PM, Artur Skawina wrote:
 Trying to make arguments you don't like go away and silencing the messenger
 is your MO.

Now that's what's called "ad hominem".

No, it's not - it's just stating the facts; this was not the first such incident.

Of course it is. The definition is simple enough, e.g. from Wikipedia: An ad hominem (Latin for "to the man"), short for argumentum ad hominem, is an argument made personally against an opponent instead of against their argument.

Hmm, I can see how you could view this as an ad hominem, given that definition, but it's not meant to be one and actually isn't - it has no bearing on the property nor ()-less calls issues; this is just about the process. Remember how you originally replied to my message, after removing everything but one sentence, which was clearly both a summary of my subjective position and deliberately phrased in a way to encourage at least some consideration wrt $subject by others making a decision. This isn't a new discussion, there's no need to restate the same arguments, from other threads, over and over again. Your response didn't provide any counterargument nor opinion on the subject; instead you chose to complain about the form and - I have no choice but to assume deliberately - misinterpret it. And asked me not to 'do that', in an attempt to manipulate the discussion. Crying "Ad Hominem!" now, after I point out that such tactics are not really helping to foster discussion, won't make it one, sorry. /I/ have no problem ignoring your comments, but others may not be as thick-skinned or not view D from the same perspective, and not willing to deal with that kind of arrogance. The number of D contributors is low enough, why drive potential ones away?
 and the choice needs to stay with the callee. But the distinction is
"sane/insane"
 for a reason - there's judgment, taste and common sense involved.
 Trusting every programmer to get it right won't work, unfortunately.

I'd say "sane/insane" is pushing it.

Normally, I'd probably agree, but in the context of removing property, but not implementing correct accessors nor enforcing calling syntax "insane" is appropriate. It's "sane/insane", because absolute terms such as "right/wrong" would be too strong; there is a large subjective component to it. artur
Jan 25 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 08:03 PM, Artur Skawina wrote:
 ...

 Having said that, I'll elaborate on the sentence you quoted above. See for
example
 Timon's code [1] here: http://dpaste.dzfl.pl/baa538af . Spot the recursion in
the
 tree-walker. This is an example of the kind of abuse of parens-less calls that
an
 unsuspecting programmer shouldn't have to deal with. Sure, in this case it's
simple
 enough, but in more complex scenarios, where the 'inorder' field/method/ufcs
 definition is not readily available, it would be extremely misleading. It's not
 reasonable to expect everyone reading the code to check every single object
field
 access, just in case the previous coder decided that the source looked "cuter"
 w/o the '()'.
 ...

Uh... class Tree(T){ InOrder!T inorder; this(){inorder = InOrder!T(this); } Tree!T l,r; T v; } auto tree(T)(Tree!T l, T v, Tree!T r){ auto t = new Tree!T; t.l=l;t.r=r;t.v=v; return t; } auto tree(T)(T v){ return tree(Tree!T.init,v,Tree!T.init); } struct InOrder(T){ this(Tree!T c){container=c;} Tree!T container; InOrder* t; mixin Yield!(q{ if (container.l !is null){ for(t=[container.l.inorder].ptr;!t.empty;t.popFront()) yield t.front; } yield container.v; if (container.r !is null){ for(t=[container.r.inorder].ptr;!t.empty;t.popFront()) yield t.front; } },T); } //InOrder!T inorder(T)(Tree!T container){ return InOrder!T(container); }
Jan 24 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 03:44 AM, deadalnix wrote:
 On Thursday, 24 January 2013 at 18:05:25 UTC, Andrei Alexandrescu wrote:
 On 1/24/13 9:47 AM, Artur Skawina wrote:
 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.

You see, this is the kind of argument that I find very damaging to the conversation. It lacks any shred of material evidence, evokes emotion, manipulates the reader's opinion (framing them into incompetent/inexperienced if they disagree), and implies an appeal to authority. Please don't do that anymore.

Let me rephrase that in a proper way. Functional style is very painful right now. Function you pass as argument are executed implicitly, function as variable don't behave like native ones, and with the new proposal, it add confusion on the function returned. It is kind of dumb that D do not promote functional style as it has shown to solve many problems that arise right now.

The main issue is horrible garbage collector performance for many small allocations. Syntactically we could do what scala does: scala> def fun()=2 fun: ()Int scala> fun : Int res0: Int = 2 scala> fun : (()=>Int) res1: () => Int = <function0>
Jan 24 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/24/13 21:13, Andrei Alexandrescu wrote:
 On 1/24/13 2:03 PM, Artur Skawina wrote:
 Trying to make arguments you don't like go away and silencing the messenger
 is your MO.

Now that's what's called "ad hominem".

No, it's not - it's just stating the facts; this was not the first such incident.
 Having said that, I'll elaborate on the sentence you quoted above. See for
example
 Timon's code [1] here: http://dpaste.dzfl.pl/baa538af . Spot the recursion in
the
 tree-walker.

How about this: insert the parens and then demonstrate how the bug is easier to spot. Wasn't any easier for me.

Bug? In Timon's code? Impossible. :) No, this is just about syntax. Some functions are not suitable for calling w/o '()', and the choice needs to stay with the callee. But the distinction is "sane/insane" for a reason - there's judgment, taste and common sense involved. Trusting every programmer to get it right won't work, unfortunately. artur
Jan 24 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/24/13 19:05, Andrei Alexandrescu wrote:
 On 1/24/13 9:47 AM, Artur Skawina wrote:
 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.

You see, this is the kind of argument that I find very damaging to the conversation. It lacks any shred of material evidence, evokes emotion, manipulates the reader's opinion (framing them into incompetent/inexperienced if they disagree), and implies an appeal to authority. Please don't do that anymore.

You're more than welcome to produce counterevidence, or ignore the arguments, for whatever reasons. Ad hominems won't work, not only because I don't take this personally, but because I'm probably the person most willing/likely to discuss any relevant issues around here (I wish there was more like us (ie me)). Trying to make arguments you don't like go away and silencing the messenger is your MO. Please don't do that anymore. Not because I ask you to, but because it does harm the language, and the "community". Trying to at least understand the other point of view and reflecting a bit can be very enlightening. Who knows, you might even learn something new. Having said that, I'll elaborate on the sentence you quoted above. See for example Timon's code [1] here: http://dpaste.dzfl.pl/baa538af . Spot the recursion in the tree-walker. This is an example of the kind of abuse of parens-less calls that an unsuspecting programmer shouldn't have to deal with. Sure, in this case it's simple enough, but in more complex scenarios, where the 'inorder' field/method/ufcs definition is not readily available, it would be extremely misleading. It's not reasonable to expect everyone reading the code to check every single object field access, just in case the previous coder decided that the source looked "cuter" w/o the '()'. artur [1] This isn't meant to single out Timon in any way; it's just a recent public code example I happened to remember. I would consider Timon one of the most helpful and knowledgeable people here - thanks for all the help and arguments, even the ones where we disagree, btw.
Jan 24 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 6:50 AM, mist wrote:
 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

It becomes way uglier with templates: some!(e1)().ufcs!(e2)().chaining!(e3)(). In fact look at the code written by Nick in _favor_ of the parens. Self-destruction at its finest.
 anything; - this drives me crazy, there is no way to understand if this

I was amazed at how quickly I got used to it.
 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.

You'll still be able to use parens. Andrei
Jan 24 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 1:35 PM, mist wrote:
 You see, contrary to UFCS chaining this is not habit or syntax issue. It
 is semantic one - I am loosing an ability to distinct data access from
 function call by simply looking at code.

This is the case with any property implementation. Andrei
Jan 24 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 03:48 AM, deadalnix wrote:
 On Thursday, 24 January 2013 at 18:35:08 UTC, mist wrote:
 Yes, I am able to use parens, but in _my_ code I also do not need
 -property or anything - I am C++ programmer after all, I can
 discipline myself to certain code style even without compiler help.
 But writing generic code and reading one of others... I am glad I have
 not had to do any high-order function generic processing yet.

I always create dumb lambda to do so as going fully functional is too painful map!(a => foo(a)) instead of map!foo . That is really annoying.

And just as pointless.
Jan 24 2013
prev sibling next sibling parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
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.
Jan 24 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 24 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 14:01, bearophile wrote:
 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?

No one can answer that.
 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.

I agree with you but Walter is very afraid of breaking code. -- /Jacob Carlborg
Jan 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 24 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 3:58 PM, mist wrote:
 Really, all this backwards-compatibility talk is a crap.

There's just a lot of evidence that suggests the contrary. Clearly we don't want or like to be conservative, but apparently we need to. Andrei
Jan 24 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 4:06 PM, mist wrote:
 On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu wrote:
 On 1/24/13 3:58 PM, mist wrote:
 Really, all this backwards-compatibility talk is a crap.

There's just a lot of evidence that suggests the contrary. Clearly we don't want or like to be conservative, but apparently we need to. Andrei

Do you read and answer only to the first sentence?

It was your second paragraph I quoted.
 Can you honestly say
 "D design is rock solid and correct, we will never be required to make
 any backwards-incompatible change"?

Clearly the design is imperfect.
 If you check those evidences, it was never breaking code alone. It was
 breaking code AND lack of any sane process that allows to stick with
 acceptable release version for longer time. And I suggest to fix the
 right thing, not freeze specs and hope all problems will fade themselves.

My understanding is that we're working on such. Andrei
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 22:06:02 mist wrote:
 On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu
 
 wrote:
 On 1/24/13 3:58 PM, mist wrote:
 Really, all this backwards-compatibility talk is a crap.

There's just a lot of evidence that suggests the contrary. Clearly we don't want or like to be conservative, but apparently we need to. Andrei

Do you read and answer only to the first sentence? Can you honestly say "D design is rock solid and correct, we will never be required to make any backwards-incompatible change"? If you check those evidences, it was never breaking code alone. It was breaking code AND lack of any sane process that allows to stick with acceptable release version for longer time. And I suggest to fix the right thing, not freeze specs and hope all problems will fade themselves.

The problem is that we have competing goals that we have to deal with 1. Fix any problems in the language so that its design is solid. 2. Avoid breaking people's code. If we don't do enough of #1, then D will have serious problems, but if we do too much of it, then we'll serious problems because with #2. Even if we end up with the perfect language when we're done, it doesn't matter much if no one's using it, and if we are forever breaking people's code, then they're not going to stick around. The trick is deciding when and how we need to and can get away with breaking code. And the longer it takes to solve major design flaws in the language which require breaking code, the more code we'll break when we do make the changes, and the more problems will have, which is one reason why it's so frustrating that it often takes quite a while to properly sort this sort of thing out. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 13:26:11 -0800, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Thursday, January 24, 2013 22:06:02 mist wrote:
 On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu

 wrote:
 On 1/24/13 3:58 PM, mist wrote:
 Really, all this backwards-compatibility talk is a crap.

There's just a lot of evidence that suggests the contrary. Clearly we don't want or like to be conservative, but apparently we need to. Andrei

Do you read and answer only to the first sentence? Can you honestly say "D design is rock solid and correct, we will never be required to make any backwards-incompatible change"? If you check those evidences, it was never breaking code alone. It was breaking code AND lack of any sane process that allows to stick with acceptable release version for longer time. And I suggest to fix the right thing, not freeze specs and hope all problems will fade themselves.

The problem is that we have competing goals that we have to deal with 1. Fix any problems in the language so that its design is solid. 2. Avoid breaking people's code. If we don't do enough of #1, then D will have serious problems, but if we do too much of it, then we'll serious problems because with #2. Even if we end up with the perfect language when we're done, it doesn't matter much if no one's using it, and if we are forever breaking people's code, then they're not going to stick around. The trick is deciding when and how we need to and can get away with breaking code. And the longer it takes to solve major design flaws in the language which require breaking code, the more code we'll break when we do make the changes, and the more problems will have, which is one reason why it's so frustrating that it often takes quite a while to properly sort this sort of thing out. - Jonathan M Davis

I don't think we can fix property (or remove it) without breaking code. So I would plead with the community to accept that. This is a very important problem to fix. Obviously deciding how to proceed is going to be difficult but I don't think that we have copious amounts of time for the community to slug it out either. You either break properties or optional parens, either way creates problems. I would argue that removing property creates more problems than removing optional parens. One is a highly delicate surgical operation on the parser to handle all the new ambiguities, more documentation to explain, and more chances to the user to D the wrong (but still acceptable) thing, and requires large amounts code refactoring. The other is a simple find/replace in user code, with some simple changes to the parser. I will always vote for the less bug-prone path. Remove Optional Parens. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 21:40:01 UTC, Adam Wilson wrote:
 Remove Optional Parens.

This has absolutely nothing to do with properties because properties are data fields, NOT functions. http://forum.dlang.org/post/fpbvfpvnjtgqbganqece forum.dlang.org
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 13:41:55 -0800, Adam D. Ruppe  
<destructionator gmail.com> wrote:

 On Thursday, 24 January 2013 at 21:40:01 UTC, Adam Wilson wrote:
 Remove Optional Parens.

This has absolutely nothing to do with properties because properties are data fields, NOT functions. http://forum.dlang.org/post/fpbvfpvnjtgqbganqece forum.dlang.org

From the compilers standpoint they are functions. It must be so. That's how they're implemented. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 21:44:12 UTC, Adam Wilson wrote:
 From the compilers standpoint they are functions. It must be 
 so. That's how they're implemented.

No, they are property functions. That's important because it lets them be rewritten at the usage point, similarly to operator overloading and various other tricks in the language, which also doesn't care about function call syntax, despite being implemented as functions. I was messing with the compiler a while ago to make my vision work. Got about 90% there, but it got too messy when doing setters. Only made 5 changes: DsymbolExp::semantic if the function this references was declared as a property, rewrite the symbol to be a call expression Thus "bar", if bar was declared as property, is rewritten into "(bar())" and the rest carries on normally. (So if the whole expression was "bar().foo", the rest of the compiler sees it as "(bar())().foo" and reacts accordingly.) DotVarExp::semantic ditto, but for members instead And the others were trying to make it work for setters in BinExp, AssignExp, and a filthy hack in CallExp itself to find the setter given a getter. The getter change, about 10 lines of code in dmd, was a success. The setters are where I tripped up and couldn't get it to work right, but this is probably because I'm not a dmd master, not because it is impossible.
Jan 24 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/24/2013 12:58 PM, mist wrote:
 <rage>Please. Go to http://wiki.dlang.org/Release_Process . Read it. Answer the
 question "Hm, does having well-defined release process with long-term support
 versions help with instability of breaking changes?". And if answer is "no"
then
 you probably should have contributed your opinion there for a long time,
because
 it _should_ to.</rage>

 Really, all this backwards-compatibility talk is a crap. There is no way we can
 say current D design is final and solid and can be polished without any
breaking
 changes. We should not argue about how bad breaking is. We should discus how to
 do those changes in the least harmful way.

Having a release process does not remove the pain of breaking changes that make users miserable because their older code no longer compiles.
Jan 24 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/13 4:49 AM, Don wrote:
 On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote:
 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.

I don't believe that is true. Remember when 'bit' was removed from the language? It didn't cause any complaints at all. This attitude is very harmful. Our real problem is that we're not making promises about what we won't change. When we haven't made such promises, we then become fearful of changing *anything*. Then we bend over backwards to avoid changing things that actually nobody cares about. This is a recipe for locking bugs into the language forever. Instead, we should be trying to continuously expand the things we guarantee will continue to work. Ideally we would be precise about the things that are likely to change, and which we don't currently guarantee.

TDPL did exactly that. For example it doesn't mention foreach_reverse or lazy. Far as I know that didn't make a difference. Andrei
Jan 25 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
25-Jan-2013 13:49, Don пишет:
 On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote:
 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.

I don't believe that is true. Remember when 'bit' was removed from the language? It didn't cause any complaints at all. This attitude is very harmful. Our real problem is that we're not making promises about what we won't change. When we haven't made such promises, we then become fearful of changing *anything*. Then we bend over backwards to avoid changing things that actually nobody cares about. This is a recipe for locking bugs into the language forever. Instead, we should be trying to continuously expand the things we guarantee will continue to work. Ideally we would be precise about the things that are likely to change, and which we don't currently guarantee.

+1 -- Dmitry Olshansky
Jan 25 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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. -- /Jacob Carlborg
Jan 24 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 8:01 AM, bearophile wrote:
 I think this silly fear of breaking user code was one of the main causes
 of the failure of  property in the first place.

No. property is bad design, pure and simple. It's great that we're acknowledging that. Andrei
Jan 24 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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; (b) property adds noise for everybody for the sake of a corner case (functions returning delegates); (c) the property discipline failed to align itself in any way with better code quality. Andrei
Jan 24 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 12:54 PM, David Nadlinger wrote:
 On Thursday, 24 January 2013 at 17:51:32 UTC, Andrei Alexandrescu wrote:
 No. The complications come from the fact that (a) nobody could agree
 what should be a  property and what shouldn't; (b)  property adds
 noise for everybody for the sake of a corner case (functions returning
 delegates); (c) the  property discipline failed to align itself in any
 way with better code quality.

The simple(r) explanation is: The current *implementation* is broken.

Simpler doesn't make it true. Andrei
Jan 24 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 18:54:00 David Nadlinger wrote:
 On Thursday, 24 January 2013 at 17:51:32 UTC, Andrei Alexandrescu
 
 wrote:
 No. The complications come from the fact that (a) nobody could
 agree what should be a  property and what shouldn't; (b)
  property adds noise for everybody for the sake of a corner
 case (functions returning delegates); (c) the  property
 discipline failed to align itself in any way with better code
 quality.

The simple(r) explanation is: The current *implementation* is broken.

Exactly. Most of the problems with property stem from the fact that it's not implemented properly, particularly with regards to the -property flag. - Jonathan M Davis
Jan 24 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 2:14 PM, Jonathan M Davis wrote:
 On Thursday, January 24, 2013 18:54:00 David Nadlinger wrote:
 On Thursday, 24 January 2013 at 17:51:32 UTC, Andrei Alexandrescu

 wrote:
 No. The complications come from the fact that (a) nobody could
 agree what should be a  property and what shouldn't; (b)
  property adds noise for everybody for the sake of a corner
 case (functions returning delegates); (c) the  property
 discipline failed to align itself in any way with better code
 quality.

The simple(r) explanation is: The current *implementation* is broken.

Exactly. Most of the problems with property stem from the fact that it's not implemented properly, particularly with regards to the -property flag.

That is because it's not well defined. Andrei
Jan 24 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 3:45 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:
 No, you merely came up with *some* specific cherry-picked examples that
 sparked *some* debate (with most of the disagreing coming from
 you).

I simply mentioned three reasons that came to mind. Andrei
Jan 24 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 13:08:08 Adam Wilson wrote:
 On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:
 On 1/24/13 3:45 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 No, you merely came up with *some* specific cherry-picked examples that
 sparked *some* debate (with most of the disagreing coming from
 you).

I simply mentioned three reasons that came to mind. Andrei

While I don't approve of Mr. Sabalausky's tone or attitude,

He does have a tendancy to get out of hand in that regard.
 the crux of
 his argument is logically sound. The problem with  property isn't
  property, it's D's insistence on optional parens. If paren usage was
 clearly defined then this would be a non-issue. I would like to point out
 that I can't think of another systems/general purpose language that has an
 calling syntax specification as vague and convoluted as D's. C#'s is
 brutally simple. Java's is brutally simple. In C/C++ everything is a
 function or field, so, brutally simple.
 
 Make D's calling syntax simpler, end optional parens!

Exactly. That's what _should_ have happened. We wouldn't have all of these problems if we'd just gone with a C#-esque property design and never had optional parens. Unfortunately however, optional parens are so popular for at least some use cases (e.g. UFCS), that I don't think that there's much chance of them going away. - Jonathan M Davis
Jan 24 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 10:24 PM, Adam Wilson wrote:
 ...

 All I can say is that in this case even with UFCS C# enforces parens
 because it's syntactically clear. Yes, it might be slightly annoying to
 have to type the (), but that's how you define a function in every other
 language. A shortcut with side-effects isn't a short-cut, it's a bug
 factory.

It is not a shortcut, it is a formatting option, and using it does not have side effects.
 And to be honest, once the language spec settles down tools
 like ReSharper/VisualAssist/etc. can take care of the extra parens.

Tools will be configurable to highlight certain constructs anyway.
 I hand type a small fraction of the parens that actually appear in my C#
 code.

It is about reading, not typing.
Jan 24 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 12:23 AM, Adam Wilson wrote:
 ...

 But what happens if t.baz returns a delegate?

You mean, a parameterless delegate. How many times does this occur that it supports nuking a entire language feature?
 Because properties, which conceptually have nothing to do with
 functions, are implemented as functions they have the same optional
 parens rules as functions.

Because the compiler is broken.
 The problem is that they aren't intended to
 be used as functions so in the case of delegate, you get massive
 explosions in the compiler. For something that should be
 straight-forward. If t.baz is a delegate than t.baz() should call the
 DELEGATE, but it doesn't...

It should for properties.
 Optional Parens Encourage Ambiguity.

We could talk about fixing that particular situation, eg, only allow paren-free calls when no parameterless callable is returned, with a very explicit error message. (Like Jesse suggests as well.) However, note that scala does the same we do now: scala> def foo()=()=>2 foo: ()() => Int scala> foo res1: () => Int = <function0> scala> foo() res2: () => Int = <function0> scala> foo()() res3: Int = 2 I do not think this is a recurring discussion topic on the scala newsgroup. I think we might actually be fine.
 Ambiguity Fosters Bugs.

Delegates not being called is noticed quickly.
Jan 24 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 8:01 PM, Timon Gehr wrote:
 On 01/25/2013 12:23 AM, Adam Wilson wrote:
 ...

 But what happens if t.baz returns a delegate?

You mean, a parameterless delegate. How many times does this occur that it supports nuking a entire language feature?
 Because properties, which conceptually have nothing to do with
 functions, are implemented as functions they have the same optional
 parens rules as functions.

Because the compiler is broken.
 The problem is that they aren't intended to
 be used as functions so in the case of delegate, you get massive
 explosions in the compiler. For something that should be
 straight-forward. If t.baz is a delegate than t.baz() should call the
 DELEGATE, but it doesn't...

It should for properties.
 Optional Parens Encourage Ambiguity.

We could talk about fixing that particular situation, eg, only allow paren-free calls when no parameterless callable is returned, with a very explicit error message. (Like Jesse suggests as well.) However, note that scala does the same we do now: scala> def foo()=()=>2 foo: ()() => Int scala> foo res1: () => Int = <function0> scala> foo() res2: () => Int = <function0> scala> foo()() res3: Int = 2 I do not think this is a recurring discussion topic on the scala newsgroup. I think we might actually be fine.
 Ambiguity Fosters Bugs.

Delegates not being called is noticed quickly.

I feel we're getting somewhere! Andrei
Jan 24 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 8:27 PM, kenji hara wrote:
 I have thought an additional idea.
 If we really want a feature to disable optional parentheses for normal
 functions, we can add  function attribute to the language spec.

 int foo();
  property int bar();
  function int baz();  // new!

 int x1 = foo();  // ok
 int x2 = foo;  // optional parentheses, allowed
 int y1 = bar();  // disallowed, calling int is meaningless
 int y2 = bar;  // ok
 int z1 = baz();  // ok
 int z2 = baz;  // *disallowed* by  function attribute

 How about?

 Kenji Hara

Brings completeness. But at this point I'm inclined to simplify, simplify, simplify. Your #1 proposal to ratify current behavior and never apply "()" deeply is very sensible. If we also find a simple way to implement writing for properties we may be able to eliminate property entirely. Andrei
Jan 24 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/24/2013 5:15 PM, kenji hara wrote:
 1. Optional parentheses for normal functions should work shallowly IMO.
 2. Optional parentheses for property functions should not work. Applying () for
 property function name always applied to its returned value.

 #1 is a ratification of current behavior. It allows the combination of UFCS and
 removing redundant ()s.
 #2 is a breaking change. If we need it, community consent is required.

There is a way to do #2 without breaking existing code. Create a new property attribute, say, prop. Imbue it with the new behavior. Leave the old property as it is, and let it cycle through the usual warning, deprecation, removal process.
Jan 25 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 00:29:52 Jonathan M Davis wrote:
 On Friday, January 25, 2013 00:19:28 Walter Bright wrote:
 On 1/24/2013 5:15 PM, kenji hara wrote:
 1. Optional parentheses for normal functions should work shallowly IMO.
 2. Optional parentheses for property functions should not work. Applying
 () for property function name always applied to its returned value.
 
 #1 is a ratification of current behavior. It allows the combination of
 UFCS and removing redundant ()s.
 #2 is a breaking change. If we need it, community consent is required.

There is a way to do #2 without breaking existing code. Create a new property attribute, say, prop. Imbue it with the new behavior. Leave the old property as it is, and let it cycle through the usual warning, deprecation, removal process.

Considering that it's always been the plan that property would be enforced such that any use of it would be illegal with parens (it's explicitly among the things tha TDPL says about property), the expectation of pretty much every D programmer is that that's how property functions are to be used, and it shouldn't come as any surprise when that's enforced. As such, I really don't think that it's a big deal if we simply start enforcing that property functions be called without parens. And if you're really concerned about breakage, then we could start with making it a warning rather than an error. But I wager that in almost all cases, any such warning or error would be triggered by a mistake rather than someone intentially using parens with an property function.

In fact, I'd argue that making property enforce that a function be called without parens would be on par with things like starting to enforce that final switch has cases for all of the values in an enum. Yes, it can break code, but it only breaks code because the feature wasn't enforcing what it was supposed to enforce per the spec. And we've made those sorts of changes before. It's really just a bug fix, albeit one that risks having a larger impact than many. Code which follows the spec won't be broken by the change. - Jonathan M Davis
Jan 25 2013
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 09:54:02 eles wrote:
 Tooo bad, I feel like the best word for that, namely " property"
 was wasted.

I dispute that we can't just use property since it was its design from the get-go that it would require that there be no parens (it's even discussed in TDPL). It's just that it hasn't been properly enforced. Making it so that it's enforced would be like when we fixed it so that the compiler enforced that final switch statements had cases for all of an enum's values. Code which followed the spec was unaffected, and for any code that _was_ affected, the new enforcement was catching a bug. - Jonathan M Davis
Jan 25 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 15:55, mist wrote:
 Meaning of  property for free functions is well-defined. Most likely
 because languages like C# does not have UFCS as far as I rememeber.

C# doesn't have UFCS but it does have a syntax for adding new methods for existing classes. The end result is the same. -- /Jacob Carlborg
Jan 25 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 16:05, mist wrote:

 Great, could you give a sample? Does it work on compile time or injects
 in run-time? Is calling of such methods allowed in usual free form?

 Unfortunately I have never been using C# in practice, only following
 materials available in the internet, would be really interesting to
 learn from their approach.

The secret is to add "this" in front of the argument type you want to the method to extend: namespace ExtensionMethods { public static class MyExtensions { public static int WordCount(this String str) { return str.Split(new char[] { ' ', '.', '?' }, StringSplitOptions.RemoveEmptyEntries).Length; } } } using ExtensionMethods; string s = "Hello Extension Methods"; int i = s.WordCount(); http://msdn.microsoft.com/en-us/library/vstudio/bb383977.aspx -- /Jacob Carlborg
Jan 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 16:16, mist wrote:

 Good. Main questions remain though: is property syntax allowed on
 extension methods? Is WordCount(s) call allowed?

I'm not particular familiar with this, perhaps someone else can answer these questions. -- /Jacob Carlborg
Jan 25 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 13:19:49 -0800, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Thursday, January 24, 2013 13:08:08 Adam Wilson wrote:
 On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu

 <SeeWebsiteForEmail erdani.org> wrote:
 On 1/24/13 3:45 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 No, you merely came up with *some* specific cherry-picked examples  


 sparked *some* debate (with most of the disagreing coming from
 you).

I simply mentioned three reasons that came to mind. Andrei

While I don't approve of Mr. Sabalausky's tone or attitude,

He does have a tendancy to get out of hand in that regard.
 the crux of
 his argument is logically sound. The problem with  property isn't
  property, it's D's insistence on optional parens. If paren usage was
 clearly defined then this would be a non-issue. I would like to point  
 out
 that I can't think of another systems/general purpose language that has  
 an
 calling syntax specification as vague and convoluted as D's. C#'s is
 brutally simple. Java's is brutally simple. In C/C++ everything is a
 function or field, so, brutally simple.

 Make D's calling syntax simpler, end optional parens!

Exactly. That's what _should_ have happened. We wouldn't have all of these problems if we'd just gone with a C#-esque property design and never had optional parens. Unfortunately however, optional parens are so popular for at least some use cases (e.g. UFCS), that I don't think that there's much chance of them going away. - Jonathan M Davis

All I can say is that in this case even with UFCS C# enforces parens because it's syntactically clear. Yes, it might be slightly annoying to have to type the (), but that's how you define a function in every other language. A shortcut with side-effects isn't a short-cut, it's a bug factory. And to be honest, once the language spec settles down tools like ReSharper/VisualAssist/etc. can take care of the extra parens. I hand type a small fraction of the parens that actually appear in my C# code. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 21:20:01 UTC, Jonathan M Davis 
wrote:
 We wouldn't have all of these problems if we'd just
 gone with a C#-esque property design

http://msdn.microsoft.com/en-us/library/w86s7x04(v=VS.80).aspx "To the user of an object, a property appears to be a field, accessing the property requires exactly the same syntax." Say it with me: properties are DATA FIELDS. Function syntax has NOTHING to do with them! We could change function syntax to require you to draw out some ASCII art of a running cat.... and it shouldn't affect properties one bit. Optional parens is a matter of function syntax. Properties are data fields, so function syntax doesn't matter to them.
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 13:34:45 -0800, Adam D. Ruppe  
<destructionator gmail.com> wrote:

 On Thursday, 24 January 2013 at 21:20:01 UTC, Jonathan M Davis wrote:
 We wouldn't have all of these problems if we'd just
 gone with a C#-esque property design

http://msdn.microsoft.com/en-us/library/w86s7x04(v=VS.80).aspx "To the user of an object, a property appears to be a field, accessing the property requires exactly the same syntax." Say it with me: properties are DATA FIELDS. Function syntax has NOTHING to do with them! We could change function syntax to require you to draw out some ASCII art of a running cat.... and it shouldn't affect properties one bit. Optional parens is a matter of function syntax. Properties are data fields, so function syntax doesn't matter to them.

The problem is that optional parens introduce ambiguity in relation to what is a property versus a function from the compilers prospective. So they are a matter of functional call syntax in that they are non-trivial for the compiler to deduce between the two. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 21:41:58 UTC, Adam Wilson wrote:
 The problem is that optional parens introduce ambiguity in 
 relation to what is a property versus a function from the 
 compilers prospective.

No, it doesn't. struct Thing { int foo() { return 0; } // method int bar; // data field property int baz() { return 0; } // data field } Thing t; t.bar = 10; // this is a data field because it is // declared as "int bar" above, // not because I didn't use parens down here t.foo; // this is a function call because t.foo is a function t.baz; // this is a data field because i declared // " property int" above, not because I left off parens here t.bar(); // error, type int has no call method t.baz(); // error, type int has no call method
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 13:45:44 -0800, Adam D. Ruppe  
<destructionator gmail.com> wrote:

 On Thursday, 24 January 2013 at 21:41:58 UTC, Adam Wilson wrote:
 The problem is that optional parens introduce ambiguity in relation to  
 what is a property versus a function from the compilers prospective.

No, it doesn't. struct Thing { int foo() { return 0; } // method int bar; // data field property int baz() { return 0; } // data field } Thing t; t.bar = 10; // this is a data field because it is // declared as "int bar" above, // not because I didn't use parens down here t.foo; // this is a function call because t.foo is a function t.baz; // this is a data field because i declared // " property int" above, not because I left off parens here t.bar(); // error, type int has no call method t.baz(); // error, type int has no call method

Right, this conversation is about removing property, which invalidates your argument by turning the data into a function, which is what we want to avoid. Also you might want to run your examples before posting them. t.baz() is NOT an error, which incidentally why the ambiguities I mentioned exist and need to be quashed. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 4:08 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 3:45 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 No, you merely came up with *some* specific cherry-picked examples that
 sparked *some* debate (with most of the disagreing coming from
 you).

I simply mentioned three reasons that came to mind. Andrei

While I don't approve of Mr. Sabalausky's tone or attitude, the crux of his argument is logically sound. The problem with property isn't property, it's D's insistence on optional parens. If paren usage was clearly defined then this would be a non-issue. I would like to point out that I can't think of another systems/general purpose language that has an calling syntax specification as vague and convoluted as D's. C#'s is brutally simple. Java's is brutally simple. In C/C++ everything is a function or field, so, brutally simple. Make D's calling syntax simpler, end optional parens!

Simplicity is clearly good, but there's something to be said about those warts in chained calls. The UFCS-enabled idioms clearly bring a strong argument to the table, there's no ignoring it. Andrei
Jan 24 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 4:56 PM, Adam Wilson wrote:
 Simplicity is clearly good, but there's something to be said about
 those warts in chained calls. The UFCS-enabled idioms clearly bring a
 strong argument to the table, there's no ignoring it.

 Andrei

Then property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions.

I'm not all that convinced, and it's easy to get wedged into a black vs white position that neglects many subtleties. Properties are DATA, well except when you need to pass fields by reference etc. at which point the syntactic glue comes unglued. There's been a lot of strong positions years ago about functions vs. procedures, statements vs. expressions, or even (the glorious 60s!) in-language I/O primitives vs. I/O as library facilities. Successful languages managed to obviate such dichotomies. Andrei
Jan 24 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 23:15:38 Adam D. Ruppe wrote:
 On Thursday, 24 January 2013 at 22:04:02 UTC, Andrei Alexandrescu
 
 wrote:
 Properties are DATA, well except when you need to pass fields
 by reference etc. at which point the syntactic glue comes
 unglued.

An enum or a literal can't be passed by reference or otherwise have the address taken either, but we don't argue about if they're data or not, and don't change barely related parts of the language over them.

However, I do think that would be able to mark variables such that they're treated as rvalues such that swapping a variable out with a property function dosen't break code (at least if http://d.puremagic.com/issues/show_bug.cgi?id=8006 gets implemented). - Jonathan M Davis
Jan 24 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
25-Jan-2013 02:32, Adam D. Ruppe пишет:
 On Thursday, 24 January 2013 at 22:28:04 UTC, Jonathan M Davis wrote:
 However, I do think that would be able to mark variables such that
 they're treated as rvalues such that swapping a
 variable out with a property function dosen't break code


IMHO this is a critical part of what a property should do - transparently swapping fields with some functional accessors. -- Dmitry Olshansky
Jan 25 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 22:28:04 UTC, Jonathan M Davis 
wrote:
 However, I do think that would be able to mark variables such 
 that they're treated as rvalues such that swapping a
 variable out with a property function dosen't break code

agreed
Jan 24 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 01:55, kenji hara wrote:
 I can imagine a situation that we might not want to treat property
 functions as DATAs simply.

 If you have a struct which have some property functions as members, and
 you'd want to serialize it:

 struct S {
     int value_;
      property int value() { return value_; }
 }

 At least, the serialization library should recognize the S.value is a
 _property function_, not a int DATA.

A serialization library would only recognize "value_" since it's an instance variable. -- /Jacob Carlborg
Jan 25 2013
prev sibling parent luka8088 <luka8088 owave.net> writes:
On 24.1.2013 23:04, Andrei Alexandrescu wrote:
 On 1/24/13 4:56 PM, Adam Wilson wrote:
 Simplicity is clearly good, but there's something to be said about
 those warts in chained calls. The UFCS-enabled idioms clearly bring a
 strong argument to the table, there's no ignoring it.

 Andrei

Then property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions.

I'm not all that convinced, and it's easy to get wedged into a black vs white position that neglects many subtleties. Properties are DATA, well except when you need to pass fields by reference etc. at which point the syntactic glue comes unglued. There's been a lot of strong positions years ago about functions vs. procedures, statements vs. expressions, or even (the glorious 60s!) in-language I/O primitives vs. I/O as library facilities. Successful languages managed to obviate such dichotomies. Andrei

Maybe this will clarify what is meant by "properties are data": // http://dpaste.dzfl.pl/822aab11 auto foo () { return { return 0; }; } property auto bar () { return { return 0; }; } void main () { auto localFoo = foo; assert(!is(typeof(localFoo) == typeof(foo))); auto localBar = bar; assert(is(typeof(localBar) == typeof(bar))); } function: auto localFoo = foo; // call foo and store the result typeof(localFoo) // typeof(data returned by foo) - function pointer typeof(foo) // typeof(function foo) - function data: auto localBar = bar; // get data represented by bar typeof(localBar) // typeof(data represented by bar) - function pointer typeof(bar) // typeof(data represented by bar) - function pointer Data represented by bar can be some value, or a function call that returns a value. As a user of that property I don't care. And I don't want my code to break if that property changes from a function pointer to a function that returns a function pointer. Hence typeof(foo) is a function, and typeof(bar) is a type of that property (type that is returned by a calling bar). I would like to emphasize that property is not a syntactic, but rather a semantic issue.
Jan 25 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 21:53:27 UTC, Adam Wilson wrote:
 Right, this conversation is about removing  property, which 
 invalidates your argument by turning the data into a function, 
 which is what we want to avoid.

Yeah, that's why I'm against the OP proposal.
 Also you might want to run your examples before posting them.

I did.... on my modified dmd where property has a less stupid (but still buggy) implementation. It works correctly there!
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 14:06:47 -0800, Adam D. Ruppe  
<destructionator gmail.com> wrote:

 On Thursday, 24 January 2013 at 21:53:27 UTC, Adam Wilson wrote:
 Right, this conversation is about removing  property, which invalidates  
 your argument by turning the data into a function, which is what we  
 want to avoid.

Yeah, that's why I'm against the OP proposal.

Hehe, so am I! :-)
 Also you might want to run your examples before posting them.

I did.... on my modified dmd where property has a less stupid (but still buggy) implementation. It works correctly there!

I see. I like it. :-) -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 15:04:20 -0800, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 01/24/2013 10:24 PM, Adam Wilson wrote:
 ...

 All I can say is that in this case even with UFCS C# enforces parens
 because it's syntactically clear. Yes, it might be slightly annoying to
 have to type the (), but that's how you define a function in every other
 language. A shortcut with side-effects isn't a short-cut, it's a bug
 factory.

It is not a shortcut, it is a formatting option, and using it does not have side effects.
 And to be honest, once the language spec settles down tools
 like ReSharper/VisualAssist/etc. can take care of the extra parens.

Tools will be configurable to highlight certain constructs anyway.
 I hand type a small fraction of the parens that actually appear in my C#
 code.

It is about reading, not typing.

*sigh* ideally yes, it's just a formating option. The problem is that right now, it's NOT. Consider: module main; import std.stdio; struct Thing { int foo() { return 0; } // method int bar; // data field property int baz() { return 0; } // data field } int main(string[] argv) { writeln("Hello D-World!"); return 0; Thing t; t.bar = 10; // this is a data field because it is // declared as "int bar" above, // not because I didn't use parens down here t.foo; // this is a function call because t.foo is a function t.baz; // this is a data field because i declared // " property int" above, not because I left off parens here t.bar(); // error, type int has no call method t.baz(); // is this a function or a property? oops have to go look at the code. } But what happens if t.baz returns a delegate? Because properties, which conceptually have nothing to do with functions, are implemented as functions they have the same optional parens rules as functions. The problem is that they aren't intended to be used as functions so in the case of delegate, you get massive explosions in the compiler. For something that should be straight-forward. If t.baz is a delegate than t.baz() should call the DELEGATE, but it doesn't... Optional Parens Encourage Ambiguity. Ambiguity Fosters Bugs. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 03:09 AM, kenji hara wrote:
 ...

  property ref int foo();
 auto x = &foo;   // x is a function pointer, or an address of returned
 value?

Address of returned value.
 This is the most sensible problem.
 (a) If typeof(x) should be a function pointer, we need to use a utility
 function to get int*.
     ref identity(T)(ref T t) { return t; }
     int* p1 = &(identity(foo));
        // foo is evaluated to ref int in function argument,
        // and identity gets through the reference.
     int* p1 = &foo.identity;
        // with UFCS, parentheses can be removed.

     This is a real issue. In phobos, the ref-ness of front property is
 actually checked in std.range.moveFront.

This is a serious issue.
 (b) If typeof(x) should be a int*, we will lose the way to getting a
 function pointer of foo.
     That is more serious than (a). If we adopt this rule, we will
 *really* get lost the way to distinguish property functions and raw data
 fields. (Note that: In current typeof(foo) already returns int. So
 AddressExp is only one way to getting (normal|property) function
 information by its type.) From the view of meta-programming, I think
 this makes a serious flaw.

We might add the necessary __traits to make up for it.
Jan 24 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d043be2408d8fca04d412a83f
Content-Type: text/plain; charset=UTF-8

2013/1/25 Adam Wilson <flyboynw gmail.com>

 On Thu, 24 Jan 2013 15:04:20 -0800, Timon Gehr <timon.gehr gmx.ch> wrote:

  On 01/24/2013 10:24 PM, Adam Wilson wrote:
 ...

 All I can say is that in this case even with UFCS C# enforces parens
 because it's syntactically clear. Yes, it might be slightly annoying to
 have to type the (), but that's how you define a function in every other
 language. A shortcut with side-effects isn't a short-cut, it's a bug
 factory.

It is not a shortcut, it is a formatting option, and using it does not have side effects. And to be honest, once the language spec settles down tools
 like ReSharper/VisualAssist/etc. can take care of the extra parens.

Tools will be configurable to highlight certain constructs anyway. I hand type a small fraction of the parens that actually appear in my C#
 code.


right now, it's NOT. Consider: module main; import std.stdio; struct Thing { int foo() { return 0; } // method int bar; // data field property int baz() { return 0; } // data field } int main(string[] argv) { writeln("Hello D-World!"); return 0; Thing t; t.bar = 10; // this is a data field because it is // declared as "int bar" above, // not because I didn't use parens down here t.foo; // this is a function call because t.foo is a function t.baz; // this is a data field because i declared // " property int" above, not because I left off parens here t.bar(); // error, type int has no call method t.baz(); // is this a function or a property? oops have to go look at the code. } But what happens if t.baz returns a delegate? Because properties, which conceptually have nothing to do with functions, are implemented as functions they have the same optional parens rules as functions. The problem is that they aren't intended to be used as functions so in the case of delegate, you get massive explosions in the compiler. For something that should be straight-forward. If t.baz is a delegate than t.baz() should call the DELEGATE, but it doesn't... Optional Parens Encourage Ambiguity. Ambiguity Fosters Bugs.

1. Optional parentheses for normal functions should work shallowly IMO. 2. Optional parentheses for property functions should not work. Applying () for property function name always applied to its returned value. #1 is a ratification of current behavior. It allows the combination of UFCS and removing redundant ()s. #2 is a breaking change. If we need it, community consent is required. Kenji Hara --f46d043be2408d8fca04d412a83f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /1/25 Adam Wilson <span dir=3D"ltr">&lt;<a href=3D"mailto:flyboynw gmail.co= m" target=3D"_blank">flyboynw gmail.com</a>&gt;</span><br><blockquote class= =3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px= ;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)= ;border-left-style:solid;padding-left:1ex"> <div class=3D""><div class=3D"h5">On Thu, 24 Jan 2013 15:04:20 -0800, Timon= Gehr &lt;<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">timon.gehr= gmx.ch</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> On 01/24/2013 10:24 PM, Adam Wilson wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> ...<br> <br> All I can say is that in this case even with UFCS C# enforces parens<br> because it&#39;s syntactically clear. Yes, it might be slightly annoying to= <br> have to type the (), but that&#39;s how you define a function in every othe= r<br> language. A shortcut with side-effects isn&#39;t a short-cut, it&#39;s a bu= g<br> factory.<br> </blockquote> <br> It is not a shortcut, it is a formatting option, and using it does not have= side effects.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> And to be honest, once the language spec settles down tools<br> like ReSharper/VisualAssist/etc. can take care of the extra parens.<br> </blockquote> <br> Tools will be configurable to highlight certain constructs anyway.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> I hand type a small fraction of the parens that actually appear in my C#<br=

<br> </blockquote> <br> It is about reading, not typing.<br> <br> <br> </blockquote> <br></div></div> *sigh* ideally yes, it&#39;s just a formating option. The problem is that r= ight now, it&#39;s NOT.<br> <br> Consider:<br> <br> module main;<br> <br> import std.stdio;<div class=3D"im"><br> <br> struct Thing {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 int foo() { return 0; } // method<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 int bar; // data field<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 property int baz() { return 0; } // data field= <br> }<br> <br></div> int main(string[] argv)<br> {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 writeln(&quot;Hello D-World!&quot;);<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;<div class=3D"im"><br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thing t;<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 t.bar =3D 10; // this is a data field because i= t is<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 // declared as &quot;int bar&quot; above,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 // not because I didn&#39;t use parens down her= e<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 t.foo; // this is a function call because t.foo= is a function<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 t.baz; // this is a data field because i declar= ed<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 // &quot; property int&quot; above, not because= I left off parens here<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 t.bar(); // error, type int has no call method<= br> <br></div> =C2=A0 =C2=A0 =C2=A0 =C2=A0 t.baz(); // is this a function or a property? o= ops have to go look at the code.<br> }<br> <br> But what happens if t.baz returns a delegate?<br> <br> Because properties, which conceptually have nothing to do with functions, a= re implemented as functions they have the same optional parens rules as fun= ctions. The problem is that they aren&#39;t intended to be used as function= s so in the case of delegate, you get massive explosions in the compiler. F= or something that should be straight-forward. If t.baz is a delegate than t= .baz() should call the DELEGATE, but it doesn&#39;t...<br> <br> Optional Parens Encourage Ambiguity. Ambiguity Fosters Bugs.</blockquote><d= iv><br></div><div>1. Optional parentheses for normal functions should work = shallowly IMO.</div><div>2. Optional parentheses for property functions sho= uld not work. Applying () for property function name always applied to its = returned value.</div> <div><br></div><div>#1 is a ratification of current behavior. It allows the= combination of UFCS and removing redundant ()s.</div><div>#2 is a breaking= change. If we need it, community consent is required.</div><div><br></div> <div>Kenji Hara</div></div></div></div> --f46d043be2408d8fca04d412a83f--
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 17:15:09 -0800, kenji hara <k.hara.pg gmail.com> wrote:

 2013/1/25 Adam Wilson <flyboynw gmail.com>

 On Thu, 24 Jan 2013 15:04:20 -0800, Timon Gehr <timon.gehr gmx.ch>  
 wrote:

  On 01/24/2013 10:24 PM, Adam Wilson wrote:
 ...

 All I can say is that in this case even with UFCS C# enforces parens
 because it's syntactically clear. Yes, it might be slightly annoying  
 to
 have to type the (), but that's how you define a function in every  
 other
 language. A shortcut with side-effects isn't a short-cut, it's a bug
 factory.

It is not a shortcut, it is a formatting option, and using it does not have side effects. And to be honest, once the language spec settles down tools
 like ReSharper/VisualAssist/etc. can take care of the extra parens.

Tools will be configurable to highlight certain constructs anyway. I hand type a small fraction of the parens that actually appear in my C#
 code.


right now, it's NOT. Consider: module main; import std.stdio; struct Thing { int foo() { return 0; } // method int bar; // data field property int baz() { return 0; } // data field } int main(string[] argv) { writeln("Hello D-World!"); return 0; Thing t; t.bar = 10; // this is a data field because it is // declared as "int bar" above, // not because I didn't use parens down here t.foo; // this is a function call because t.foo is a function t.baz; // this is a data field because i declared // " property int" above, not because I left off parens here t.bar(); // error, type int has no call method t.baz(); // is this a function or a property? oops have to go look at the code. } But what happens if t.baz returns a delegate? Because properties, which conceptually have nothing to do with functions, are implemented as functions they have the same optional parens rules as functions. The problem is that they aren't intended to be used as functions so in the case of delegate, you get massive explosions in the compiler. For something that should be straight-forward. If t.baz is a delegate than t.baz() should call the DELEGATE, but it doesn't... Optional Parens Encourage Ambiguity. Ambiguity Fosters Bugs.

1. Optional parentheses for normal functions should work shallowly IMO. 2. Optional parentheses for property functions should not work. Applying () for property function name always applied to its returned value. #1 is a ratification of current behavior. It allows the combination of UFCS and removing redundant ()s. #2 is a breaking change. If we need it, community consent is required. Kenji Hara

I can completely agree with this change. It is perfectly workable to fix properties without changing optional parens. I just won't use them :-P -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--e89a8f3bae491576cb04d412d611
Content-Type: text/plain; charset=UTF-8

2013/1/25 Adam Wilson <flyboynw gmail.com>

 On Thu, 24 Jan 2013 17:15:09 -0800, kenji hara <k.hara.pg gmail.com>
 wrote:

 1. Optional parentheses for normal functions should work shallowly IMO.
 2. Optional parentheses for property functions should not work. Applying
 ()
 for property function name always applied to its returned value.

 #1 is a ratification of current behavior. It allows the combination of
 UFCS
 and removing redundant ()s.
 #2 is a breaking change. If we need it, community consent is required.

 Kenji Hara

I can completely agree with this change. It is perfectly workable to fix properties without changing optional parens. I just won't use them :-P

I have thought an additional idea. If we really want a feature to disable optional parentheses for normal functions, we can add function attribute to the language spec. int foo(); property int bar(); function int baz(); // new! int x1 = foo(); // ok int x2 = foo; // optional parentheses, allowed int y1 = bar(); // disallowed, calling int is meaningless int y2 = bar; // ok int z1 = baz(); // ok int z2 = baz; // *disallowed* by function attribute How about? Kenji Hara --e89a8f3bae491576cb04d412d611 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= 2013/1/25 Adam Wilson <span dir=3D"ltr">&lt;<a href=3D"mailto:flyboynw gmai= l.com" target=3D"_blank">flyboynw gmail.com</a>&gt;</span><br><blockquote c= lass=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom= :0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,= 204);border-left-style:solid;padding-left:1ex"> On Thu, 24 Jan 2013 17:15:09 -0800, kenji hara &lt;<a href=3D"mailto:k.hara= .pg gmail.com" target=3D"_blank">k.hara.pg gmail.com</a>&gt; wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class= =3D"h5"> <br></div></div><div class=3D"im"> 1. Optional parentheses for normal functions should work shallowly IMO.<br> 2. Optional parentheses for property functions should not work. Applying ()= <br> for property function name always applied to its returned value.<br> <br> #1 is a ratification of current behavior. It allows the combination of UFCS= <br> and removing redundant ()s.<br> #2 is a breaking change. If we need it, community consent is required.<br> <br> Kenji Hara<br> </div></blockquote> <br> I can completely agree with this change. It is perfectly workable to fix pr= operties without changing optional parens. I just won&#39;t use them :-P</b= lockquote><div><br></div><div>I have thought an additional idea.</div> <div>If we really want a feature to disable optional parentheses for normal= functions, we can add function attribute to the language spec.</div><div>= <br></div><div>int foo();</div><div> property int bar();</div><div> functio= n=C2=A0int=C2=A0baz(); =C2=A0// new!</div> <div><br></div><div>int x1 =3D foo(); =C2=A0// ok</div><div>int x2 =3D foo;= =C2=A0// optional parentheses, allowed</div><div>int y1 =3D bar(); =C2=A0/= / disallowed, calling int is meaningless<br></div><div>int y2 =3D bar; =C2= =A0// ok</div><div>int z1 =3D baz(); =C2=A0// ok</div> <div>int z2 =3D baz; =C2=A0// *disallowed* by function attribute</div><div=
<br></div><div>How about?</div><div><br></div><div>Kenji Hara</div></div><=

--e89a8f3bae491576cb04d412d611--
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 17:27:52 -0800, kenji hara <k.hara.pg gmail.com> wrote:

 2013/1/25 Adam Wilson <flyboynw gmail.com>

 On Thu, 24 Jan 2013 17:15:09 -0800, kenji hara <k.hara.pg gmail.com>
 wrote:

 1. Optional parentheses for normal functions should work shallowly IMO.
 2. Optional parentheses for property functions should not work.  
 Applying
 ()
 for property function name always applied to its returned value.

 #1 is a ratification of current behavior. It allows the combination of
 UFCS
 and removing redundant ()s.
 #2 is a breaking change. If we need it, community consent is required.

 Kenji Hara

I can completely agree with this change. It is perfectly workable to fix properties without changing optional parens. I just won't use them :-P

I have thought an additional idea. If we really want a feature to disable optional parentheses for normal functions, we can add function attribute to the language spec. int foo(); property int bar(); function int baz(); // new! int x1 = foo(); // ok int x2 = foo; // optional parentheses, allowed int y1 = bar(); // disallowed, calling int is meaningless int y2 = bar; // ok int z1 = baz(); // ok int z2 = baz; // *disallowed* by function attribute How about? Kenji Hara

Very clever Mr. Hara, I like it a lot! But good luck convincing Walter+Andrei. :-) -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d044306b0c352b804d412f970
Content-Type: text/plain; charset=UTF-8

2013/1/25 kenji hara <k.hara.pg gmail.com>
 I have thought an additional idea.
 If we really want a feature to disable optional parentheses for normal
 functions, we can add  function attribute to the language spec.

 int foo();
  property int bar();
  function int baz();  // new!

 int x1 = foo();  // ok
 int x2 = foo;  // optional parentheses, allowed
 int y1 = bar();  // disallowed, calling int is meaningless
 int y2 = bar;  // ok
 int z1 = baz();  // ok
 int z2 = baz;  // *disallowed* by  function attribute

I think calling a function which does not annotated with attribute without parenthesis is legal, Even if a function has some side-effects and a name looks like verb. Because native English grammar does not require parentheses. He runs(). // normal function call He runs. // optional parentheses Kenji Hara --f46d044306b0c352b804d412f970 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /1/25 kenji hara <span dir=3D"ltr">&lt;<a href=3D"mailto:k.hara.pg gmail.co= m" target=3D"_blank">k.hara.pg gmail.com</a>&gt;</span><blockquote class=3D= "gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;ma= rgin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo= rder-left-style:solid;padding-left:1ex"> <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
<br></div><div>I have thought an additional idea.</div>

functions, we can add function attribute to the language spec.</div><div>= <br></div><div>int foo();</div><div> property int bar();</div><div> functio= n=C2=A0int=C2=A0baz(); =C2=A0// new!</div> <div><br></div><div>int x1 =3D foo(); =C2=A0// ok</div><div>int x2 =3D foo;= =C2=A0// optional parentheses, allowed</div><div>int y1 =3D bar(); =C2=A0/= / disallowed, calling int is meaningless<br></div><div>int y2 =3D bar; =C2= =A0// ok</div><div>int z1 =3D baz(); =C2=A0// ok</div> <div>int z2 =3D baz; =C2=A0// *disallowed* by function attribute</div></di= v></div></div></blockquote><div><br></div><div>I think calling a function w= hich does not annotated with attribute without parenthesis is legal,=C2=A0= Even if a function has some side-effects and a name looks like verb. Becaus= e native English grammar does not require parentheses.</div> <div><br></div><div>He runs(). =C2=A0// normal function call<br></div><div>= <div>He runs. =C2=A0 =C2=A0// optional parentheses<br></div><br class=3D"">= </div><div>Kenji Hara</div></div></div></div> --f46d044306b0c352b804d412f970--
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 01:38:01 UTC, kenji hara wrote:
 2013/1/25 kenji hara <k.hara.pg gmail.com>
 I have thought an additional idea.
 If we really want a feature to disable optional parentheses 
 for normal
 functions, we can add  function attribute to the language spec.

 int foo();
  property int bar();
  function int baz();  // new!

 int x1 = foo();  // ok
 int x2 = foo;  // optional parentheses, allowed
 int y1 = bar();  // disallowed, calling int is meaningless
 int y2 = bar;  // ok
 int z1 = baz();  // ok
 int z2 = baz;  // *disallowed* by  function attribute

I think calling a function which does not annotated with attribute without parenthesis is legal, Even if a function has some side-effects and a name looks like verb. Because native English grammar does not require parentheses. He runs(). // normal function call He runs. // optional parentheses Kenji Hara

English grammar don't have any functional style enable. It is not possible to return runs itself.
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 01:28:05 UTC, kenji hara wrote:
 I have thought an additional idea.
 If we really want a feature to disable optional parentheses for 
 normal
 functions, we can add  function attribute to the language spec.

 int foo();
  property int bar();
  function int baz();  // new!

 int x1 = foo();  // ok
 int x2 = foo;  // optional parentheses, allowed
 int y1 = bar();  // disallowed, calling int is meaningless
 int y2 = bar;  // ok
 int z1 = baz();  // ok
 int z2 = baz;  // *disallowed* by  function attribute

 How about?

function seems like an extra complication. Ambiguity between setter and getter for properties when UFCS come into play are not solved. Functional style is impaired as you can't pass regular function around, just function . You'll still find trap in generic code around the behavior of regular functions.
Jan 24 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d043be2405e53b104d4164a34
Content-Type: text/plain; charset=UTF-8

2013/1/25 deadalnix <deadalnix gmail.com>
  function seems like an extra complication. Ambiguity between setter and
 getter for  properties when UFCS come into play are not solved. Functional
 style is impaired as you can't pass regular function around, just  function
 . You'll still find trap in generic code around the behavior of regular
 functions.

That's a good point. We need to solve another ambiguity about top-level property function which have a parameter, between top-level property setter and UFCS property getter. module abc; property int foo(int n); void main() { foo = 1; // top-level property setter 1.foo; // property getter with UFCS } We cannot distinguish the two usages without adding any new features. Kenji Hara --f46d043be2405e53b104d4164a34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /1/25 deadalnix <span dir=3D"ltr">&lt;<a href=3D"mailto:deadalnix gmail.com= " target=3D"_blank">deadalnix gmail.com</a>&gt;</span><blockquote class=3D"= gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;mar= gin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor= der-left-style:solid;padding-left:1ex"> function seems like an extra complication. Ambiguity between setter and ge= tter for properties when UFCS come into play are not solved. Functional st= yle is impaired as you can&#39;t pass regular function around, just functi= on . You&#39;ll still find trap in generic code around the behavior of regu= lar functions.<br> </blockquote></div><br></div><div class=3D"gmail_extra">That&#39;s a good p= oint. We need to solve another ambiguity about top-level property function= which have a parameter, between top-level property setter and UFCS propert= y getter.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">module abc;= </div><div class=3D"gmail_extra"> property int foo(int n);</div><div class= =3D"gmail_extra"><br></div><div class=3D"gmail_extra">void main() {</div><d= iv class=3D"gmail_extra"> =C2=A0 foo =3D 1; =C2=A0// top-level property setter</div><div class=3D"gma= il_extra">=C2=A0 1.foo; =C2=A0// property getter with UFCS</div><div class= =3D"gmail_extra">}</div><div class=3D"gmail_extra"><br></div><div class=3D"= gmail_extra">We cannot distinguish the two usages without adding any new fe= atures.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Kenji Hara<= /div></div> --f46d043be2405e53b104d4164a34--
Jan 24 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 25 January 2013 at 01:28:05 UTC, kenji hara wrote:
 2013/1/25 Adam Wilson <flyboynw gmail.com>

 On Thu, 24 Jan 2013 17:15:09 -0800, kenji hara 
 <k.hara.pg gmail.com>
 wrote:

 1. Optional parentheses for normal functions should work 
 shallowly IMO.
 2. Optional parentheses for property functions should not 
 work. Applying
 ()
 for property function name always applied to its returned 
 value.

 #1 is a ratification of current behavior. It allows the 
 combination of
 UFCS
 and removing redundant ()s.
 #2 is a breaking change. If we need it, community consent is 
 required.

 Kenji Hara

I can completely agree with this change. It is perfectly workable to fix properties without changing optional parens. I just won't use them :-P

I have thought an additional idea. If we really want a feature to disable optional parentheses for normal functions, we can add function attribute to the language spec. int foo(); property int bar(); function int baz(); // new! int x1 = foo(); // ok int x2 = foo; // optional parentheses, allowed

I dunno, but for me the line above is a function pointer that is stored into an integer for later retrieval and use.
Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 08:19:28 UTC, Walter Bright wrote:
 On 1/24/2013 5:15 PM, kenji hara wrote:
 1. Optional parentheses for normal functions should work 
 shallowly IMO.
 2. Optional parentheses for property functions should not 
 work. Applying () for
 property function name always applied to its returned value.

 #1 is a ratification of current behavior. It allows the 
 combination of UFCS and
 removing redundant ()s.
 #2 is a breaking change. If we need it, community consent is 
 required.

There is a way to do #2 without breaking existing code. Create a new property attribute, say, prop. Imbue it with the new behavior. Leave the old property as it is, and let it cycle through the usual warning, deprecation, removal process.

Yes, or maybe we should adopt a sane release process . . .
Jan 25 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d043c07d4835ee604d418ec35
Content-Type: text/plain; charset=UTF-8

2013/1/25 Walter Bright <newshound2 digitalmars.com>

 On 1/24/2013 5:15 PM, kenji hara wrote:

 1. Optional parentheses for normal functions should work shallowly IMO.
 2. Optional parentheses for property functions should not work. Applying
 () for
 property function name always applied to its returned value.

 #1 is a ratification of current behavior. It allows the combination of
 UFCS and
 removing redundant ()s.
 #2 is a breaking change. If we need it, community consent is required.

There is a way to do #2 without breaking existing code. Create a new property attribute, say, prop. Imbue it with the new behavior. Leave the old property as it is, and let it cycle through the usual warning, deprecation, removal process.

Instead, we can simply change the semantic behavior, when -property switch is specified. Because -property switch should have been used for enabling "experimental feature". In phobos, we need to care the semantic change by adding `static if` branches. By the following code we can detect whether the -property switch is really specified or not. enum enforceProperty = !__traits(compiles, { int prop(){ return 1; } int n = prop; }); Kenji Hara --f46d043c07d4835ee604d418ec35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /1/25 Walter Bright <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digi= talmars.com" target=3D"_blank">newshound2 digitalmars.com</a>&gt;</span><br=
<blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px=

r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> On 1/24/2013 5:15 PM, kenji hara wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> 1. Optional parentheses for normal functions should work shallowly IMO.<br> 2. Optional parentheses for property functions should not work. Applying ()= for<br> property function name always applied to its returned value.<br> <br> #1 is a ratification of current behavior. It allows the combination of UFCS= and<br> removing redundant ()s.<br> #2 is a breaking change. If we need it, community consent is required.<br> </blockquote> <br> There is a way to do #2 without breaking existing code.<br> <br> Create a new property attribute, say, prop. Imbue it with the new behavior= . Leave the old property as it is, and let it cycle through the usual warn= ing, deprecation, removal process.<br></blockquote><div><br></div><div> Instead, we can simply change the semantic behavior, when -property switch = is specified.</div><div>Because -property switch should have been used for = enabling &quot;experimental feature&quot;.</div><div><br></div><div>In phob= os, we need to care the semantic change by adding `static if` branches.</di= v> <div><div>By the following code we can detect whether the -property switch = is really specified or not.</div><div><br></div><div>enum enforceProperty = =3D !__traits(compiles, {</div><div>=C2=A0 =C2=A0 int prop(){ return 1; }</= div><div> =C2=A0 =C2=A0 int n =3D prop;</div><div>});</div></div><div><br></div><div>= Kenji Hara</div></div></div></div> --f46d043c07d4835ee604d418ec35--
Jan 25 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 25 January 2013 at 08:19:28 UTC, Walter Bright wrote:
 On 1/24/2013 5:15 PM, kenji hara wrote:
 Create a new property attribute, say,  prop. Imbue it with the 
 new behavior. Leave the old  property as it is, and let it 
 cycle through the usual warning, deprecation, removal process.

I think the way picked to do the change is, now, of secondary importance. Prioritary is to decide what is the aim of that change. OTOH, I reallyy do not like " prop" (proposal? proposition? property? proponent?), maybe a better name is needed. Tooo bad, I feel like the best word for that, namely " property" was wasted.
Jan 25 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 22:08, Adam Wilson wrote:

 While I don't approve of Mr. Sabalausky's tone or attitude, the crux of
 his argument is logically sound. The problem with  property isn't
  property, it's D's insistence on optional parens. If paren usage was
 clearly defined then this would be a non-issue. I would like to point
 out that I can't think of another systems/general purpose language that
 has an calling syntax specification as vague and convoluted as D's. C#'s
 is brutally simple. Java's is brutally simple. In C/C++ everything is a
 function or field, so, brutally simple.

 Make D's calling syntax simpler, end optional parens!

There are many languages that allow optional parentheses when calling a function. Ruby, CoffeeScript and Groovy to mention a few. -- /Jacob Carlborg
Jan 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 10:49, deadalnix wrote:

 From what I see on CofeeScript website, it has a VERY different
 semantic than D on function.

How do you mean? Well it has the same semantics as JavaScript since it's compiled to JavaScript. -- /Jacob Carlborg
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 05:35:19 UTC, kenji hara wrote:
 module abc;
  property int foo(int n);

 void main() {
   foo = 1;  // top-level property setter
   1.foo;  // property getter with UFCS
 }

 We cannot distinguish the two usages without adding any new 
 features.

 Kenji Hara

"1.foo" must be compile error here. Makes as much sense as int a; void main() { 1.a; } Property must behave exactly like data or it is not a property.
Jan 25 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Friday, 25 January 2013 at 10:56:14 UTC, mist wrote:
 On Friday, 25 January 2013 at 05:35:19 UTC, kenji hara wrote:
 module abc;
  property int foo(int n);

 void main() {
  foo = 1;  // top-level property setter
  1.foo;  // property getter with UFCS
 }

 We cannot distinguish the two usages without adding any new 
 features.

 Kenji Hara

"1.foo" must be compile error here. Makes as much sense as int a; void main() { 1.a; } Property must behave exactly like data or it is not a property.

I don't see 1.foo the way you see it. I see it like this: property bool is_zero(X value) { return value == 0; } void main() { X value; value.is_zero; } It's just that X happens to be a built-in type, instead of a user-defined type. But I don't see why should that matter.
Jan 25 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Friday, 25 January 2013 at 14:18:43 UTC, TommiT wrote:
 ... But I don't see why should that matter.

But I don't see why that should matter. ...aced it.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 14:18:43 UTC, TommiT wrote:
 I don't see 1.foo the way you see it. I see it like this:

  property bool is_zero(X value)
 {
     return value == 0;
 }

 void main()
 {
     X value;
     value.is_zero;
 }

 It's just that X happens to be a built-in type, instead of a 
 user-defined type. But I don't see why should that matter.

It is a tempting attempt to save two symbols of typing that completely breaks property semantics. I am objecting against it. With all my passion. Use value.is_zero() for UFCS magic.
Jan 25 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Friday, 25 January 2013 at 14:29:22 UTC, mist wrote:
 It is a tempting attempt to save two symbols of typing that 
 completely breaks property semantics. I am objecting against 
 it. With all my passion.
 Use value.is_zero() for UFCS magic.

My understanding of the point of UFCS has been that it enables you to add functionality to a type without actually modifying the type. So, let me get this straight... are you saying that the following code snippet breaks property semantics? struct MyType {} property bool is_valid(MyType) { return true; } void main() { MyType mt; mt.is_valid; } Or, are you saying that we shouldn't be able to add properties to built-in types? Or are you saying something else entirely?
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
Meaning of  property for free functions is well-defined. Most 
likely because languages like C# does not have UFCS as far as I 
rememeber.

I see two possible approaches here:

1)
-----
 property void symbol1(Data);
 property Data symbol1();
Data symbol2;
...
symbol1 = symbol2; // allowed, symbol1 behaves same as symbol2 
for user
symbol2.symbol1; // prohibited, symbol1 is semantically a global 
variable
-----

2)
-----
 property void symbol1(Data);
 property Data symbol1();
Data symbol2;
...
symbol1 = symbol2; // prohibited, symbol1 has meaning only within 
UFCS and imitates Data member.
symbol2.symbol1; // Fine, rewritten as symbol1(symbol2), follows 
general property rules but for compound symbol
-----

First one seems more natural to me, but I can live with either 
approach. Not both. Also please mote that UFCS is meant for 
enhancing data type functionality with free functions, not 
implementing every possible feature available to that data type 
with native syntax.
Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 14:55:09 UTC, mist wrote:
 Meaning of  property for free functions is well-defined. Most 
 likely because languages like C# does not have UFCS as far as I 
 rememeber.

 I see two possible approaches here:

 1)
 -----
  property void symbol1(Data);
  property Data symbol1();
 Data symbol2;
 ...
 symbol1 = symbol2; // allowed, symbol1 behaves same as symbol2 
 for user
 symbol2.symbol1; // prohibited, symbol1 is semantically a 
 global variable
 -----

 2)
 -----
  property void symbol1(Data);
  property Data symbol1();
 Data symbol2;
 ...
 symbol1 = symbol2; // prohibited, symbol1 has meaning only 
 within UFCS and imitates Data member.
 symbol2.symbol1; // Fine, rewritten as symbol1(symbol2), 
 follows general property rules but for compound symbol
 -----

 First one seems more natural to me, but I can live with either 
 approach. Not both. Also please mote that UFCS is meant for 
 enhancing data type functionality with free functions, not 
 implementing every possible feature available to that data type 
 with native syntax.

See what is proposed here : http://forum.dlang.org/thread/kdqrnl$13ft$1 digitalmars.com?page=3#post-uagknsecziepoedcabvr:40forum.dlang.org
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 15:02:46 UTC, Jacob Carlborg wrote:
 On 2013-01-25 15:55, mist wrote:
 Meaning of  property for free functions is well-defined. Most 
 likely
 because languages like C# does not have UFCS as far as I 
 rememeber.

C# doesn't have UFCS but it does have a syntax for adding new methods for existing classes. The end result is the same.

Great, could you give a sample? Does it work on compile time or injects in run-time? Is calling of such methods allowed in usual free form? Unfortunately I have never been using C# in practice, only following materials available in the internet, would be really interesting to learn from their approach.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 15:05:11 UTC, deadalnix wrote:
 See what is proposed here : 
 http://forum.dlang.org/thread/kdqrnl$13ft$1 digitalmars.com?page=3#post-uagknsecziepoedcabvr:40forum.dlang.org

Looks somewhat solid to me, with some disagreement on UFCS side :) Will reply with comments to that post.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 15:13:21 UTC, Jacob Carlborg wrote:
 The secret is to add "this" in front of the argument type you 
 want to the method to extend:

 namespace ExtensionMethods
 {
     public static class MyExtensions
     {
         public static int WordCount(this String str)
         {
             return str.Split(new char[] { ' ', '.', '?' },
                              
 StringSplitOptions.RemoveEmptyEntries).Length;
         }
     }
 }

 using ExtensionMethods;

 string s = "Hello Extension Methods";
 int i = s.WordCount();

 http://msdn.microsoft.com/en-us/library/vstudio/bb383977.aspx

Good. Main questions remain though: is property syntax allowed on extension methods? Is WordCount(s) call allowed?
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 19:54:29 UTC, Nick Sabalausky wrote:
 I think you might have misunderstood it. What he's trying to do 
 is use
 UFCS to add a property to a type instead of adding a function.

I got it. What I am questioning is that allowing this in some way is a must. And somewhat changed my mind after that :) There is semantic ambiguity here currently (rules are too lax) that I have described in wiki http://wiki.dlang.org/Property_Discussion_Wrap-up - and I pretty much like proposal there.
Jan 25 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/13 3:18 PM, Rob T wrote:
 On Friday, 25 January 2013 at 20:10:01 UTC, Nick Sabalausky wrote:
 What really got me upset about it was that here we have one of my
 favorite modern language features, properties, and then all of a sudden
 *both* the top #1 and #2 people behind D start trying to gut it if not
 outright remove it from the language entirely, instead of enacting, or
 at least promising to *eventually* enact, the long overdue fixes I've
 been anxiously awaiting.

If I correctly understand Walters proposal and Andrei's view point, neither are proposing to fully axe property-like behavior. I stand to be corrected, but they both seem to think that enforcement through property is not required, and that's the main point being put on the chopping block. Walter and Andrei may want to clarify since I cannot speak for them.

That's right with the amendment that we're looking for a solution, not pushing one. Even the title of the thread is a question. Clearly properties are good to have. In an ideal world we wouldn't need a keyword for them and we'd have some simple rules for determining property status (especially when it comes to writes). If syntactic help is necessary, so be it. We want to make the language better, not worse. Andrei
Jan 25 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 22:20, Andrei Alexandrescu wrote:

 That's right with the amendment that we're looking for a solution, not
 pushing one. Even the title of the thread is a question.

 Clearly properties are good to have. In an ideal world we wouldn't need
 a keyword for them and we'd have some simple rules for determining
 property status (especially when it comes to writes). If syntactic help
 is necessary, so be it. We want to make the language better, not worse.

It's always possible to avoid keywords in favor of syntax. Example: Declaring a getter: int foo {} Just as a regular function declaration but without the parentheses. Declaring a setter: void foo= (int value) {} Append an equal sign to the function name. -- /Jacob Carlborg
Jan 26 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-26 16:06, Nicolas Sicard wrote:

 How would you declare a template property? The getter would be ambiguous
 with a regular function declaration, wouldn't it?

Right... didn't think of that. -- /Jacob Carlborg
Jan 26 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/13 8:21 AM, Jacob Carlborg wrote:
 On 2013-01-25 22:20, Andrei Alexandrescu wrote:

 That's right with the amendment that we're looking for a solution, not
 pushing one. Even the title of the thread is a question.

 Clearly properties are good to have. In an ideal world we wouldn't need
 a keyword for them and we'd have some simple rules for determining
 property status (especially when it comes to writes). If syntactic help
 is necessary, so be it. We want to make the language better, not worse.

It's always possible to avoid keywords in favor of syntax. Example: Declaring a getter: int foo {} Just as a regular function declaration but without the parentheses. Declaring a setter: void foo= (int value) {} Append an equal sign to the function name.

This is interesting. I wonder how to make it work for UFCS functions (which _do_ have one argument). Andrei
Jan 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-26 17:29, Andrei Alexandrescu wrote:

 This is interesting. I wonder how to make it work for UFCS functions
 (which _do_ have one argument).

There's two problems with the getter syntax. 1. How to distinguish a template property from a regular function 2. How to distinguish a property without an implementation from a variable declaration -- /Jacob Carlborg
Jan 26 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2013 5:21 AM, Jacob Carlborg wrote:
 On 2013-01-25 22:20, Andrei Alexandrescu wrote:

 That's right with the amendment that we're looking for a solution, not
 pushing one. Even the title of the thread is a question.

 Clearly properties are good to have. In an ideal world we wouldn't need
 a keyword for them and we'd have some simple rules for determining
 property status (especially when it comes to writes). If syntactic help
 is necessary, so be it. We want to make the language better, not worse.

It's always possible to avoid keywords in favor of syntax. Example: Declaring a getter: int foo {} Just as a regular function declaration but without the parentheses.

Problems if you want to declare the getter but not provide an implementation.
 Declaring a setter:

 void foo= (int value) {}

 Append an equal sign to the function name.

It is rather similar to a variable declaration with initializer: T foo = expression;
Jan 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-27 02:23, Walter Bright wrote:

 Problems if you want to declare the getter but not provide an
 implementation.

Yeah, I noticed that. And declaring a tempalte property.
 It is rather similar to a variable declaration with initializer:

     T foo = expression;

Yeah, you're right. -- /Jacob Carlborg
Jan 27 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-26 22:48, Artur Skawina wrote:

 Hmm, the current state of them being defined by two separate functions really
 isn't ideal. But introducing new keywords or magic identifiers just for this
 does not seem right.

     class A
     {
         private int i;
         int foo {
             out { return i; }
             in(int v) { i = v; }
         }
     }

 or

     class A
     {
         private int i;
          property foo {
             int out { return i; }
             in(int v) { i = v; }
         }
     }

That might conflict with contracts, which also uses "in" and "out". -- /Jacob Carlborg
Jan 27 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-27 13:52, Artur Skawina wrote:

 It overloads the keywords, but afaict should be unambiguous and is not
 worse than the other meanings of 'in' (operator, modifier). But I haven't
 really used contracts w/ D (the basic features need to work right first,
 before worrying about extras like that); somebody who actually uses them
 would be in a better position to determine if overloading 'in' and 'out'
 further would be too confusing.

I'm not talking about confusing. I'm thinking if it's ambiguous or not and how to attach contracts to a property with this syntax. -- /Jacob Carlborg
Jan 27 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/27/2013 02:27 PM, Jacob Carlborg wrote:
 On 2013-01-27 13:52, Artur Skawina wrote:

 It overloads the keywords, but afaict should be unambiguous and is not
 worse than the other meanings of 'in' (operator, modifier). But I haven't
 really used contracts w/ D (the basic features need to work right first,
 before worrying about extras like that); somebody who actually uses them
 would be in a better position to determine if overloading 'in' and 'out'
 further would be too confusing.

I'm not talking about confusing. I'm thinking if it's ambiguous or not and how to attach contracts to a property with this syntax.

class A{ private int i; int foo{ out out(result){assert(result<=0);}body{return i; } in(int v)in{assert(v<=0);}out{assert(foo<=0);}body{ i = v; } } }
Jan 27 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/27/13 13:02, Jacob Carlborg wrote:
 On 2013-01-26 22:48, Artur Skawina wrote:
 
 Hmm, the current state of them being defined by two separate functions really
 isn't ideal. But introducing new keywords or magic identifiers just for this
 does not seem right.

     class A
     {
         private int i;
         int foo {
             out { return i; }
             in(int v) { i = v; }
         }
     }

 or

     class A
     {
         private int i;
          property foo {
             int out { return i; }
             in(int v) { i = v; }
         }
     }

That might conflict with contracts, which also uses "in" and "out".

It overloads the keywords, but afaict should be unambiguous and is not worse than the other meanings of 'in' (operator, modifier). But I haven't really used contracts w/ D (the basic features need to work right first, before worrying about extras like that); somebody who actually uses them would be in a better position to determine if overloading 'in' and 'out' further would be too confusing. I mentioned this as a possibility, but am not actually convinced that it's a good idea yet. Things like mixin in getters and setters via separate templates would be impaired - this may be unusual, but doesn't meet the "insane" criteria, so shouldn't be disallowed. Which means several property blocks would have to be allowed and effectively merged together. artur
Jan 27 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/27/13 03:48, Rob T wrote:
 On Sunday, 27 January 2013 at 01:11:05 UTC, H. S. Teoh wrote:
 On Sun, Jan 27, 2013 at 01:15:29AM +0100, Rob T wrote:
 We can almost implement properties as a regular struct

You do it like this: import std.stdio; struct IntProp { int __impl; property /* <-- ah, the irony! */ int value() { return __impl + 123; } alias value this; // watch this magic void opAssign(int val) { __impl = val - 123; } } struct S { IntProp prop; } void main() { S s; writeln(s.prop); s.prop = 321; writeln(s.prop); } T

Ah cool! You don't really need property however if we adopt the optional () unless that's to be enforced. The really nice thing about this, is we can return the struct as a ref, and it still works, and also take the address of the struct and it continues to work. Even better I can add more member functions to it and expand on what it can do. The "property as a function" approach is far more limiting and has issues, such as ref returns and taking the address. Anyone know what's missing or what won't work with this approach?

auto w = Widget(); w.width = 3; w.height = 14; auto a = w.area; Consider an implementation of Widget where some/all of these fields are properties. Also, does adding a "virtual" area property (ie one calculated on demand from the others) influence the layout of the object? Should it? IOW, there are many problems with such a solution, some of which can be worked around, others fixed with relatively small language changes (legalizing zero-sized objects, making a static-outer implementation cleanly doable etc). But would there really be enough gain to justify making properties that much more complicated? The present approach is a reasonable compromise, it just needs proper call handling. Consider the case, that is some times brought up here, where you use a library which at some point is changed and some object fields are replaced by properties. You recompile your code with that newer version. What keeps working? What breaks? Which breakages can be avoided? Which ones would you really want to examine and handle manually? Any field->property change breaks the ABI, but this can only be avoided by preemptively using accessors. That doesn't affect property as such, except that having some kind of syntax sugar would make creating the required forwarders easier. Handling property evaluation correctly not only makes sense, it's necessary to make them work correctly. But further "improvements" bring few extra benefits, while complicating the language. Parens-less function calls are a much bigger problem; I can't see much gain from "cleaning up" the property design. While killing property /is/ an option, it's not a good one either, especially if ()-enforcement on all calls doesn't happen before such a change. artur
Jan 27 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 15:45:42 Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 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.

I've never understood what's so hard about knowing what should and shouldn't be considered a property. It's generally very clear IMHO, and if clarification is needed, C# has some excellent guidelines for it, as a number of people keep pointing out. Really, it comes down primarily to whether a function would make sense as a variable.
 (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.

Indeed.
 (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).

I think that you're being too extreme in your language and tone here, but I have to agree. - Jonathan M Davis
Jan 24 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/26/13 20:10, Maxim Fomin wrote:
 On Saturday, 26 January 2013 at 13:21:37 UTC, Jacob Carlborg wrote:
 It's always possible to avoid keywords in favor of syntax. Example:

 Declaring a getter:

 int foo {}

 Just as a regular function declaration but without the parentheses.

 Declaring a setter:

 void foo= (int value) {}

 Append an equal sign to the function name.

This looks nice, but I favor for C# properties. The root of the issue is that in C/C++/D there is tremendous difference between object types and functions types (which are incompatible) and property is like a bridge between them - I think that is why the feature is demanded. However in D a property is essentially a function. Few characteristics that are intrinsic to data types are typeof(prop) which is data type for properties and parenthesis-less access. There is no property as a special entity per se. In C# property and getter/setter are separated, so there is no confusion between data and functions. In D it would look like this: class A { private int i; property int foo // may be without property at all? { get { return i; } set { i = value; } } } In this solution property is not defined by naming of two separate functions and is independent of any function in general.

Hmm, the current state of them being defined by two separate functions really isn't ideal. But introducing new keywords or magic identifiers just for this does not seem right. class A { private int i; int foo { out { return i; } in(int v) { i = v; } } } or class A { private int i; property foo { int out { return i; } in(int v) { i = v; } } } artur
Jan 26 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jan 24 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
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.
Jan 24 2013
prev sibling next sibling parent "ponce" <spam spam.org> writes:
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.
Jan 24 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jan 24 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
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.

Under the proposed rules, which of the lines in the output of the following program will be the same? --- import std.stdio; int globalInt = 42; auto ref g() { return globalInt; }; auto globalG = &g; auto ref f() { return globalG; } void main() { writeln("&globalInt: ", &globalInt); writeln("globalInt: ", globalInt); writeln("&globalG: ", &globalG); writeln("globalG: ", globalG); writeln("---"); writeln("&f: ", &f); writeln("&f(): ", &f()); writeln("&g: ", &g); writeln("&g(): ", &g()); } --- Also, don't forget that property was actually introduced to solve specific syntactic issues, not just because somebody didn't like the laxness of the previous rules. Now, yes, the current implementation in DMD doesn't solve the issues, while introducing new issues by disallowing parameterless function calls altogether. But I think the last larger discussion on the topic some two to three months ago produced a set of property rules that would actually work. I think there is a summary in DIP21. Anyway, I think you should turn your proposal into a DIP, and better sooner than later so that the details on the edge cases, impact in terms of breaking code, … aren't lost in an endless forum discussion. David
Jan 24 2013
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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
 
 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.
 
 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.

I can live with omitted parentheses (*). However, what's really ugly is picking the unintended form in case of a setter (i.e. both, "obj.prop(value)" instead of "obj.prop = value;", or "countElements = obj;" instead of "obj.countElements()"). And in my experience, people /will/ mix the different forms all over the place. So although I know that some people have a different opinion, I still find it a very useful thing to be able to force correct usage up to a certain degree - stylistically and to avoid ambiguities (not only for the compiler, but also for a human reader). Adam's proposal solves this nicely and it's about as simple as it gets. (*) IMO they are kind of ugly semantically if they are omitted for anything else than properties or UFCS-template functions, but you may well call that a matter of taste
 
 3. Parens are required for calling delegates or function pointers.
 
 4. No more  property.

Jan 24 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jan 24 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 24 2013
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
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
Jan 24 2013
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
--00504502b05b8a168704d408eb6b
Content-Type: text/plain; charset=ISO-8859-1

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

As much as I want to agree, I also feel this comes as too little, too late to come to this conclusion now. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --00504502b05b8a168704d408eb6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 4 January 2013 08:34, Walter Bright <span dir=3D"ltr">&lt;<a href=3D"mailto= :newshound2 digitalmars.com" target=3D"_blank">newshound2 digitalmars.com</= a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">This has turned into a monster. We&#39;ve ta= ken 2 or 3 wrong turns somewhere.<br> <br> Perhaps we should revert to a simple set of rules.<br> <br> 1. Empty parens are optional. If there is an ambiguity with the return valu= e taking (), the () go on the return value.<br> <br> 2. the:<br> =A0 =A0f =3D g<br> rewrite to:<br> =A0 =A0f(g)<br> only happens if f is a function that only has overloads for () and (one arg= ument). No variadics.<br> <br> 3. Parens are required for calling delegates or function pointers.<br> <br> 4. No more property.<br> </blockquote></div><br><br></div><div class=3D"gmail_extra">As much as I wa= nt to agree, I also feel this comes as too little, too late to come to this= conclusion now.<br clear=3D"all"></div><div class=3D"gmail_extra"><br><br>= -- <br> Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --00504502b05b8a168704d408eb6b--
Jan 24 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 8:38 AM, Iain Buclaw wrote:
 On 24 January 2013 08:34, Walter Bright <newshound2 digitalmars.com
 <mailto: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.



 As much as I want to agree, I also feel this comes as too little, too
 late to come to this conclusion now.

Too little is a good thing actually! Andrei
Jan 24 2013
prev sibling next sibling parent d coder <dlang.coder gmail.com> writes:
--0015175907a476e09e04d408f76b
Content-Type: text/plain; charset=ISO-8859-1

 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 :-) --0015175907a476e09e04d408f76b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D= "gmail_extra">As much as I want to agree, I also feel this comes as too lit= tle, too late to come to this conclusion now.<div class=3D"yj6qo ajU"> <div id=3D":333" class=3D"ajR" tabindex=3D"0"></div></div></div></blockquot= e></div><br>+1<div><br></div><div>And therefor we should take out property= ASAP :-)</div><div><br></div> --0015175907a476e09e04d408f76b--
Jan 24 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.

I'm so happy to read this !!!!
 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'm so unhappy to read this :((((((( Ok let me be more constructive. The current state of thing have 2 issues : on is that non properties are conflated with properties, and the other is that setter is conflated with getter. You solution isn't good because it conflate things even more. Here is my proposal : 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. 2. funName() call the function. Rationale : function as variable or defined in the source now behave the same way (expect the deprecated & behavior). It makes it easier to write generic code, and in general consistency is a plus (easier to learn the language, less dark corner case to consider, easier interaction with other features). 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. 7a. A function can be defined as both setter and getter, and cumulate both behavior. 7b. property is deprecated and redefined as setter *and* getter for a transitional period. 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 9. UFCS without () are delegate like construct : void foo(T t) {} T t; t.foo; // Is a struct with a function pointer and t. (equivalent to a delegate). The struct member's type is the same as the first argument. If a copy is necessary postblit is called - but will not be called at function call. If foo take a reference, a pointer is stored. t.foo(); // call foo with t as parameter. 10. To allow chain of UFCS calls without () everywhere, an opDispatch is defined in object.d : the function/delegate get's called and the result is used as parameter for foo. This eliminate the need for () on all functions of an UFCS chain expect the last one, which is a price to pay for cleanly defined, unambiguous semantic. Waiting for the shitstorm . . .
Jan 24 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 24 2013
parent Jacob Carlborg <doob me.com> writes:
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
Jan 24 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 8:41 AM, deadalnix wrote:
[snip]
 Waiting for the shitstorm . . .

Nothing like that at least from me but I can plainly say this proposal has merit but will never get implemented. Andrei
Jan 24 2013
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 01/24/2013 12:57 PM, Andrei Alexandrescu wrote:
 On 1/24/13 8:41 AM, deadalnix wrote:
 [snip]
 Waiting for the shitstorm . . .

Nothing like that at least from me but I can plainly say this proposal has merit but will never get implemented. Andrei

Wait, so Walter would be willing to ice property, but deprecating it in favor of this meritorious proposal will never happen? I, for one, would love to see good ideas go into the language that I like to use. I'd be willing to s/ property/ getter| setter/ all of my code for this. I wonder how hard it would be to write a tool that does the conversion and gets the disambiguation right in 90% of the cases...
Jan 25 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 24 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 24 2013
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jan 24 2013
next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 24.01.2013 20:14, schrieb Jonathan M Davis:
 On Thursday, January 24, 2013 14:43:33 Adam D. Ruppe wrote:
 No, god no. This would break code AGAIN and still not fix the
 problems, instead introducing new ones!

 (...)

Yes. I think that it's fairly clear that we need to do something like this. Getting rid of property is throwing out the baby with the bathwater. Not having it is a complete mess. And plenty of corner cases have been shown just in this thread which show how not having property causes problems, completely aside from the issue of whether you should be allowed to call functions without parens. Personally, I'd love strict property enforcement, but I think that it's clear at this point that that's not going to fly. However, a solution like this which is effectively weak property enforcement (parens illegal on property functions but optional for normal functions) fixes the worst technical problems caused by the lack of property, and this particular proposal seems like a solid way to go about it. - Jonathan M Davis

I see it exactly the same way.
Jan 24 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
29-Jan-2013 17:27, Alvaro пишет:
 I agree with Adam's view and I really think  property is a good thing.

 APIs have to specify their semantics and clearly distinguish properties
 from functions, which may be implemented similarly but *mean* different
 things. Basically a property is a *thing* or a characteristic, normally
 a noun, whereas a property is an action, normally a verb.

A typo pretty much ruined otherwise good point :) -- Dmitry Olshansky
Jan 29 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Thursday, 24 January 2013 at 12:13:57 UTC, Bernard Helyer 
wrote:
 On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright 
 wrote:

  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.

I would say: kill -property, not property.
Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
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.
Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
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.
Jan 24 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
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
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 24 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--bcaec51962c9e0136804d4095dc1
Content-Type: text/plain; charset=ISO-8859-1

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 :-)

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'; --bcaec51962c9e0136804d4095dc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 4 January 2013 13:40, d coder <span dir=3D"ltr">&lt;<a href=3D"mailto:dlang= .coder gmail.com" target=3D"_blank">dlang.coder gmail.com</a>&gt;</span> wr= ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"> <div class=3D"im"><br><div class=3D"gmail_quote"><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"><div class=3D"gmail_extra">As much as I want to agree, I also feel thi= s comes as too little, too late to come to this conclusion now.<div> <div></div></div></div></blockquote></div><br></div>+1<div><br></div><div>A= nd therefor we should take out property ASAP :-)</div><div><br></div> </blockquote></div><br></div><div class=3D"gmail_extra">Not going to happen= .=A0 Effectively what is being proposed here is that we are going to be stu= ck with the current state of property for the next 7 years, and no bugs wi= ll be fixed on it as its on deprecation.<br clear=3D"all"> </div><div class=3D"gmail_extra"><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ?= p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --bcaec51962c9e0136804d4095dc1--
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 24 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Jan 24 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
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.
Jan 24 2013
prev sibling next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
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.
Jan 24 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--14dae93991639ce95c04d40ab35b
Content-Type: text/plain; charset=UTF-8

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.

--14dae93991639ce95c04d40ab35b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">Absolutely agree.</p> <p dir=3D"ltr">I think it&#39;s pretty weak to say property is a monster/f= ailure, and then look at C# for instance where it&#39;s great.<br> Finish the deed!</p> <p dir=3D"ltr">Your set of proposed rules are far more complex and non-unif= orm... what is the advantage to that complexity?</p> <div class=3D"gmail_quote">On 24 Jan 2013 19:15, &quot;Bernard Helyer&quot;= &lt;<a href=3D"mailto:b.helyer gmail.com">b.helyer gmail.com</a>&gt; wrote= :<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> This has turned into a monster. We&#39;ve taken 2 or 3 wrong turns somewher= e.<br> <br> Perhaps we should revert to a simple set of rules.<br> <br> 1. Empty parens are optional. If there is an ambiguity with the return valu= e taking (), the () go on the return value.<br> <br> 2. the:<br> =C2=A0 =C2=A0f =3D g<br> rewrite to:<br> =C2=A0 =C2=A0f(g)<br> only happens if f is a function that only has overloads for () and (one arg= ument). No variadics.<br> <br> 3. Parens are required for calling delegates or function pointers.<br> <br> 4. No more property.<br> </blockquote> <br> This is lazy design, plain and simple. You say it&#39;s turned into<br> a monster, but property, at its core, is simpler than the heuristics<br> you&#39;ve demonstrated here. To my mind, property, properly implemented<b= r> is simple:<br> <br> property functions may be called with no parens or with assignment as<br> the singular argument. Non property functions may not.<br> <br> There. No complications. The only complications come from D&#39;s history.<= br> And then you want to turn it back? This seems a terrible idea -- the<br> deed is done, pull the trigger. Make property mandatory for property<br> functions.<br> <br> <br> -Bernard.<br> </blockquote></div> --14dae93991639ce95c04d40ab35b--
Jan 24 2013
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Thu, Jan 24, 2013 at 4:53 PM, Nick Treleaven
<ntrel-public yahoo.co.uk> wrote:

 write!"%s\n" = someExpression;

 :-p

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

I made a stab at it in a template tutorial that can be found on github: https://github.com/PhilippeSigaud/D-templates-tutorial You can grab the pdf, it's on section 5.11, p. 168 (Statically-Checked Writeln) Use example: cwritefln!"For sample #%d, the results are (%s, %f)"( 0, "foo", 3.14);
Jan 24 2013
prev sibling next sibling parent "Robert Jacques" <rjacque2 live.johnshopkins.edu> writes:
On Thu, 24 Jan 2013 02:34:42 -0600, 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.

vote++
Jan 24 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 24 January 2013 at 17:51:32 UTC, Andrei Alexandrescu 
wrote:
 No. The complications come from the fact that (a) nobody could 
 agree what should be a  property and what shouldn't; (b) 
  property adds noise for everybody for the sake of a corner 
 case (functions returning delegates); (c) the  property 
 discipline failed to align itself in any way with better code 
 quality.

The simple(r) explanation is: The current *implementation* is broken. David
Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Thursday, 24 January 2013 at 17:49:18 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 6:50 AM, mist wrote:
 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

It becomes way uglier with templates: some!(e1)().ufcs!(e2)().chaining!(e3)(). In fact look at the code written by Nick in _favor_ of the parens. Self-destruction at its finest.

I can hardly see any problems in your code sample. Syntax inconvenience means nothing when compared to semantic inconvenience. It is just matter of visual preferences after all, you can get used to it quite fast.
 anything; - this drives me crazy, there is no way to 
 understand if this

I was amazed at how quickly I got used to it.

 ...

 You'll still be able to use parens.


 Andrei

You see, contrary to UFCS chaining this is not habit or syntax issue. It is semantic one - I am loosing an ability to distinct data access from function call by simply looking at code. There is nothing I can get used to - in a sane design I have this info, in D I do not. You have been just shown a few very good examples regarding functions, returning delegates - it is exactly the case where it shines. Yes, I am able to use parens, but in _my_ code I also do not need -property or anything - I am C++ programmer after all, I can discipline myself to certain code style even without compiler help. But writing generic code and reading one of others... I am glad I have not had to do any high-order function generic processing yet.
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 14:43:33 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.

Yes. I think that it's fairly clear that we need to do something like this. Getting rid of property is throwing out the baby with the bathwater. Not having it is a complete mess. And plenty of corner cases have been shown just in this thread which show how not having property causes problems, completely aside from the issue of whether you should be allowed to call functions without parens. Personally, I'd love strict property enforcement, but I think that it's clear at this point that that's not going to fly. However, a solution like this which is effectively weak property enforcement (parens illegal on property functions but optional for normal functions) fixes the worst technical problems caused by the lack of property, and this particular proposal seems like a solid way to go about it. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
One thing I am interested to hear from ones who think allowing 
no-parens calls is fine is the following snippet:

http://dpaste.1azy.net/cd2f759e

------------------------------------------------------------
import std.stdio;

alias Delegate1 = int delegate();
alias Delegate2 = Delegate1 delegate();

Delegate2 func()
{
	writeln("Function");
	return (){
		writeln("First delegate");
		return (){
			writeln("Second delegate");
			return 42;
		};
	};
}

int call(alias func)()
{
	return func;
}

void main()
{
	writeln("Case 1");
	func;
	writeln("Case 2");
	func();
	writeln("Case 3");
	func()();
	writeln("Case 4");
	auto tmp = func();
	// tmp; // Error: var has no effect in expression (tmp)
}
------------------------------------------------------------

Upon any design choice questions should asked:
1) How this should behave to be consistent?
2) Should this error be an error?
3) How much special casing are you ready to throw in?

Also I really like an addition with prohibiting to use  property 
functions _with_ parens. Add this to prohibiting no-parens calls 
for normal ones and you will get my ideal solution, strict and 
clear.

And I still don't see why it won't fly. Yes, it will break user 
code. No, this is not an issue. At this point it is clear some 
design mistakes need to be corrected without stockpiling 
workarounds and one of major goals for new release process was to 
allow breaking changes with least possible user inconvenience. If 
it is not the case, then new release process has failed as much 
as  property.
Jan 24 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 24 Jan 2013 12:51:32 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 
 No. The complications come from the fact that (a) nobody could agree 
 what should be a  property and what shouldn't;

There are only 2 kinds of programmers: Those who read the C# guidelines for properties and those who didn't. Seriously, I never found it difficult to decide if something should be a property, the C#/.NET folks have pretty clear rules.
 (b)  property adds
 noise for everybody for the sake of a corner case (functions
 returning delegates); 

Partially true, although the real question is whether the additional () are really noise or actually useful. A hardcore C programmer (wants to see every function call) and a ruby developer could probably have a long discussion about that.
(c) the  property discipline failed to align
 itself in any way with better code quality.

It's hard to verify if code quality changed if the feature isn't properly implemented. Even if it was properly implemented comparing code quality probably isn't easy.
Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Thursday, 24 January 2013 at 20:00:18 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 1:35 PM, mist wrote:
 You see, contrary to UFCS chaining this is not habit or syntax 
 issue. It
 is semantic one - I am loosing an ability to distinct data 
 access from
 function call by simply looking at code.

This is the case with any property implementation. Andrei

Not really. Good property usage is somewhat similar to unsafe cast usage - you say to others "Yes, I know what I am doing, please do not pay attention that this data is in fact function". The very point of properties is to be used almost indistinguishable from data and if this usage pattern fails - property author has lied and this is not really a property. And because of issues like "+=" it is rather difficult (if possible) to define good properties in D now.
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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/
Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
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.
Jan 24 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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).
Jan 24 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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).
Jan 24 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jan 24 2013
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 01/24/2013 03:45 PM, Jonathan M Davis wrote:
 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.

I think what you want is semantic property rewriting. Please see this: http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semanticrewritingofproperties
 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

Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
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.
Jan 24 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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?
Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote:
 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.

<rage>Please. Go to http://wiki.dlang.org/Release_Process . Read it. Answer the question "Hm, does having well-defined release process with long-term support versions help with instability of breaking changes?". And if answer is "no" then you probably should have contributed your opinion there for a long time, because it _should_ to.</rage> Really, all this backwards-compatibility talk is a crap. There is no way we can say current D design is final and solid and can be polished without any breaking changes. We should not argue about how bad breaking is. We should discus how to do those changes in the least harmful way.
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 21:47:38 mist wrote:
 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:

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.

Being able to swap out a public variable with a function without having to change any code using it is arguably the primary reasons that property functions exist in the first place. Yes, making it so that the property function has a _side-effect_ is a bug, but replacing variables with property functions is not. A classic example of why it's useful is when you refactor a class such that a public variable becomes a calculated value such that it doesn't make sense to have a variable for it anymore. Instead of breaking all of the code that uses the variable by changing it a function, you change it to be a property function, and all of the code which used it continues to compile and work just fine. D's properties need some work before that will really work properly (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=8006 ), but it works just fine with property implementations in other languages (e.g. C#). - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 3:58 PM, mist wrote:
 Really, all this backwards-compatibility talk is a crap.

There's just a lot of evidence that suggests the contrary. Clearly we don't want or like to be conservative, but apparently we need to. Andrei

Do you read and answer only to the first sentence? Can you honestly say "D design is rock solid and correct, we will never be required to make any backwards-incompatible change"? If you check those evidences, it was never breaking code alone. It was breaking code AND lack of any sane process that allows to stick with acceptable release version for longer time. And I suggest to fix the right thing, not freeze specs and hope all problems will fade themselves.
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 13:00:35 -0800, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Thursday, January 24, 2013 21:47:38 mist wrote:
 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:

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.

Being able to swap out a public variable with a function without having to change any code using it is arguably the primary reasons that property functions exist in the first place. Yes, making it so that the property function has a _side-effect_ is a bug, but replacing variables with property functions is not. A classic example of why it's useful is when you refactor a class such that a public variable becomes a calculated value such that it doesn't make sense to have a variable for it anymore. Instead of breaking all of the code that uses the variable by changing it a function, you change it to be a property function, and all of the code which used it continues to compile and work just fine. D's properties need some work before that will really work properly (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=8006 ), but it works just fine with property implementations in other languages (e.g. C#). - Jonathan M Davis

++ to Mr. Davis! This is much more concise way of stating what I was trying to say. And it is an argument that should NOT be lightly dismissed, it is a very real, very common problem. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 3:45 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:
 No, you merely came up with *some* specific cherry-picked examples that
 sparked *some* debate (with most of the disagreing coming from
 you).

I simply mentioned three reasons that came to mind. Andrei

While I don't approve of Mr. Sabalausky's tone or attitude, the crux of his argument is logically sound. The problem with property isn't property, it's D's insistence on optional parens. If paren usage was clearly defined then this would be a non-issue. I would like to point out that I can't think of another systems/general purpose language that has an calling syntax specification as vague and convoluted as D's. C#'s is brutally simple. Java's is brutally simple. In C/C++ everything is a function or field, so, brutally simple. Make D's calling syntax simpler, end optional parens! -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 7:41 PM, kenji hara wrote:
 I think that the "optional parentheses" feature for normal functions
 should always work in _shallowly_. Even if a function returns some
 callable object, "optional parentheses" should not applied to the return
 object recursively.

 That means:
 void delegate() foo() { ... }
 void main() {
    auto x = foo();  // typeof(x) == void delegate()
    auto y = foo;    // typeof(y) == void delegate()
 }

 Kenji Hara

Interesting, so that would mean if anyone ever wants to get the delegate AND call it in one shot would need to write: foo()(). I think this proposal has merit. Andrei
Jan 24 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 9:11 PM, Jonathan M Davis wrote:
 I believe that that's what we have now. The problem is when you want a
 property which returns a delegate. And for that, we need  property. Getting
 rid of  property makes it a problem, whereas with  property, it can work - as
 can property functions which return delegates.

Well how about we just renounce those for the sake of simplification. Andrei
Jan 24 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 03:38:20 Jonathan M Davis wrote:
 On Thursday, January 24, 2013 21:24:05 Andrei Alexandrescu wrote:
 On 1/24/13 9:11 PM, Jonathan M Davis wrote:
 I believe that that's what we have now. The problem is when you want a
 property which returns a delegate. And for that, we need  property.
 Getting
 rid of  property makes it a problem, whereas with  property, it can work
 -
 as can property functions which return delegates.

Well how about we just renounce those for the sake of simplification.

Without explicit properties you can't switch back and forth between something being a property function and a variable - which is one of the main points of properties in the first place. With explicit properties, it's possible. Also, I think that there's real value from an API perspective to mark what is and isn't intended to be used as a property.

And actually, something far more important than any of those reasons is the issue of setters. We've focused most of this discussion on optional parens and the situation with getter properties, but setter properties and their issues are also important. Would you want code like this to compile? range.popFront = 17; container.linearRemove = range; path.baseName = ".xyz"; str.icmp = "hello"; enforce(a == b) = "msg"; arr.sameHead = arr2; With property, we can restrict the functions which can be used with the setter syntax to functions where that makes sense. Without it, all kinds of ridiculous code like the code above would be allowed. Allowing optional parens is one thing, but conflating that with properties is something else entirely. Property functions are not just functions which are called without parens, and we shouldn't act like they are. - Jonathan M Davis
Jan 24 2013
prev sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d043c07d41520ec04d415a0d3
Content-Type: text/plain; charset=UTF-8

2013/1/25 Jonathan M Davis <jmdavisProg gmx.com>

 And actually, something far more important than any of those reasons is the
 issue of setters. We've focused most of this discussion on optional parens
 and
 the situation with getter properties, but setter properties and their
 issues
 are also important. Would you want code like this to compile?

 range.popFront = 17;
 container.linearRemove = range;
 path.baseName = ".xyz";
 str.icmp = "hello";
 enforce(a == b) = "msg";
 arr.sameHead = arr2;

 With  property, we can restrict the functions which can be used with the
 setter syntax to functions where that makes sense. Without it, all kinds of
 ridiculous code like the code above would be allowed.

 Allowing optional parens is one thing, but conflating that with properties
 is
 something else entirely. Property functions are not just functions which
 are
 called without parens, and we shouldn't act like they are.

I have explained an additional rule in #1a.
 1a. Optional parentheses for normal functions is just allowed for the

 int foo();
 foo(); // ok
 foo; // ok,  from #1

 void bar(int);
 bar(1); // ok
 bar = 1;  // disallowed, from #1a

If based on that, such situations which you are worried will not occur. Kenji Hara --f46d043c07d41520ec04d415a0d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /1/25 Jonathan M Davis <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg = gmx.com" target=3D"_blank">jmdavisProg gmx.com</a>&gt;</span><br><blockquot= e class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bot= tom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,2= 04,204);border-left-style:solid;padding-left:1ex"> <div class=3D""><div class=3D"h5">And actually, something far more importan= t than any of those reasons is the<br></div></div> issue of setters. We&#39;ve focused most of this discussion on optional par= ens and<br> the situation with getter properties, but setter properties and their issue= s<br> are also important. Would you want code like this to compile?<br> <br> range.popFront =3D 17;<br> container.linearRemove =3D range;<br> path.baseName =3D &quot;.xyz&quot;;<br> str.icmp =3D &quot;hello&quot;;<br> enforce(a =3D=3D b) =3D &quot;msg&quot;;<br> arr.sameHead =3D arr2;<br> <br> With property, we can restrict the functions which can be used with the<br=

<br> ridiculous code like the code above would be allowed.<br> <br> Allowing optional parens is one thing, but conflating that with properties = is<br> something else entirely. Property functions are not just functions which ar= e<br> called without parens, and we shouldn&#39;t act like they are.</blockquote>= <div><br></div><div>I have explained an additional rule in #1a.</div><div><= br></div><div style=3D"font-family:arial,sans-serif;font-size:14px">&gt;=C2= =A01a.=C2=A0Optional parentheses for normal functions is just allowed for t= he getter usage.</div> <div style=3D"font-family:arial,sans-serif;font-size:14px">&gt;=C2=A0=C2=A0= <br></div><div style=3D"font-family:arial,sans-serif;font-size:14px">&gt;= =C2=A0int foo();</div><div style=3D"font-family:arial,sans-serif;font-size:= 14px">&gt;=C2=A0foo(); // ok<br> </div><div style=3D"font-family:arial,sans-serif;font-size:14px">&gt;=C2=A0= foo; // ok,=C2=A0 from=C2=A0#1</div><div style=3D"font-family:arial,sans-se= rif;font-size:14px">&gt;=C2=A0=C2=A0<br></div><div style=3D"font-family:ari= al,sans-serif;font-size:14px"> &gt;=C2=A0void bar(int);<br></div><div style=3D"font-family:arial,sans-seri= f;font-size:14px">&gt;=C2=A0bar(1); // ok</div><div style=3D"font-family:ar= ial,sans-serif;font-size:14px">&gt; bar =3D 1; =C2=A0// disallowed, from #1= a</div><div class=3D"" style=3D"font-family:arial,sans-serif;font-size:14px= "> <br class=3D""></div><div>=C2=A0If based on that, such situations which you= are worried will not occur.</div><div><br></div><div>Kenji Hara</div></div=
</div></div>

--f46d043c07d41520ec04d415a0d3--
Jan 24 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 03:11, Jonathan M Davis wrote:
 On Thursday, January 24, 2013 21:01:33 Andrei Alexandrescu wrote:
 Interesting, so that would mean if anyone ever wants to get the delegate
 AND call it in one shot would need to write: foo()().

 I think this proposal has merit.

I believe that that's what we have now.

Yes, that's the way it's always been since the D1 days. -- /Jacob Carlborg
Jan 25 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 7:44 PM, Adam D. Ruppe wrote:
 On Friday, 25 January 2013 at 00:42:09 UTC, kenji hara wrote:
 I think that the "optional parentheses" feature for normal functions
 should always work in _shallowly_.

I agree. This is the way it makes sense (and the way it is now).

So would Kenji's proposal float your boat? Andrei
Jan 24 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 27, 2013 at 01:15:29AM +0100, Rob T wrote:
 We can almost implement properties as a regular struct

You do it like this: import std.stdio; struct IntProp { int __impl; property /* <-- ah, the irony! */ int value() { return __impl + 123; } alias value this; // watch this magic void opAssign(int val) { __impl = val - 123; } } struct S { IntProp prop; } void main() { S s; writeln(s.prop); s.prop = 321; writeln(s.prop); } T -- Gone Chopin. Bach in a minuet.
Jan 26 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Sunday, 27 January 2013 at 01:11:05 UTC, H. S. Teoh wrote:
 On Sun, Jan 27, 2013 at 01:15:29AM +0100, Rob T wrote:
 We can almost implement properties as a regular struct

You do it like this: import std.stdio; struct IntProp { int __impl; property /* <-- ah, the irony! */ int value() { return __impl + 123; } alias value this; // watch this magic void opAssign(int val) { __impl = val - 123; } } struct S { IntProp prop; } void main() { S s; writeln(s.prop); s.prop = 321; writeln(s.prop); } T

Ah cool! You don't really need property however if we adopt the optional () unless that's to be enforced. The really nice thing about this, is we can return the struct as a ref, and it still works, and also take the address of the struct and it continues to work. Even better I can add more member functions to it and expand on what it can do. The "property as a function" approach is far more limiting and has issues, such as ref returns and taking the address. Anyone know what's missing or what won't work with this approach? --rt
Jan 26 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
It would be cool if we could declare variables with anonymous 
types;

struct { opAssign() {} } foo;
Jan 26 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Sunday, 27 January 2013 at 02:54:55 UTC, Adam D. Ruppe wrote:
 It would be cool if we could declare variables with anonymous 
 types;

 struct { opAssign() {} } foo;

This would be much easier to understand: alias foo struct { opAssign() {} }; Is "singleton structures", a.k.a. properties, a good name for these?
Jan 26 2013
prev sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Sunday, 27 January 2013 at 05:32:25 UTC, Zach the Mystic wrote:
 On Sunday, 27 January 2013 at 02:54:55 UTC, Adam D. Ruppe wrote:
 It would be cool if we could declare variables with anonymous 
 types;

 struct { opAssign() {} } foo;

This would be much easier to understand: alias foo struct { opAssign() {} }; Is "singleton structures", a.k.a. properties, a good name for these?

Actually, I don't even think you need alias: foo struct { opAssign() {} }
Jan 26 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Thursday, 24 January 2013 at 21:00:49 UTC, Jonathan M Davis 
wrote:
 Being able to swap out a public variable with a function 
 without having to
 change any code using it is arguably the primary reasons that 
 property
 functions exist in the first place. ...

Yes, but not just any function. Side-effect free function that controls access to data. And Adam suggested it is fine to use properties to add side-effects to data assignments which is drastically different. I agree with all your words so it is probably just misunderstanding.
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 13:14:00 -0800, mist <none none.none> wrote:

 On Thursday, 24 January 2013 at 21:00:49 UTC, Jonathan M Davis wrote:
 Being able to swap out a public variable with a function without having  
 to
 change any code using it is arguably the primary reasons that property
 functions exist in the first place. ...

Yes, but not just any function. Side-effect free function that controls access to data. And Adam suggested it is fine to use properties to add side-effects to data assignments which is drastically different. I agree with all your words so it is probably just misunderstanding.

Actually I said that in C# is possible to write properties with side-effects, but that it runs counter to guidelines. I personally do NOT write properties with side-effects. I was attempting to illustrate in a [much to] concise way why optional parens are bad... -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent "mist" <none none.none> writes:
%s/Adam/eles/g
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 21:09:39 UTC, Adam Wilson wrote:
 The problem with  property isn't  property, it's D's
 insistence on optional parens.

No, this isn't a problem; function call syntax has nothing whatsoever to do with property because a property is NOT logically a function! This is so important: a property is supposed to be indistinguishable from a data member. That's the fundamental definition. It should be fully interchangeable for a plain data member. In other words, as far as the user is concerned, a property *is* a data member, NOT a function! If functions have optional parens, that changes nothing about how you access data members.... and since properties are data members, it changes absolutely nothing about them either. If we required data to be accessed with foo->bar and methods to be called [foo:bar].... a property would be accessed foo->bar. The method syntax is irrelevant. That the property is implemented with a function call should not be known to the user code.
Jan 24 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
"more extensive processing" does not necessarily involve side 
effects.

beside that, as long as those side effects only affects the 
instance owning that property, nothing is wrong about it.

changing a normal member variable could also result in changing 
the instance's state and behaviour (think that the variable is a 
flag).
Jan 24 2013
prev sibling next sibling parent "Nathan M. Swan" <nathanmswan gmail.com> writes:
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.

What about code that's always ignored property? int delegate() _del; int delegate() getDelegate() { return _del; } auto del = getDelegate(); // does _del get called? Just a thought, NMS
Jan 24 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jan 24, 2013, at 1:40 PM, Nathan M. Swan <nathanmswan 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 =


=20
 Perhaps we should revert to a simple set of rules.
=20
 1. Empty parens are optional. If there is an ambiguity with the =


=20
 2. the:
   f =3D g
 rewrite to:
   f(g)
 only happens if f is a function that only has overloads for () and =


=20
 3. Parens are required for calling delegates or function pointers.
=20
 4. No more  property.

What about code that's always ignored property? =20 =20 int delegate() _del; =20 int delegate() getDelegate() { return _del; } =20 auto del =3D getDelegate(); // does _del get called?

I think a clarification of rule 1 is that parens will be = right-associative. So in your example, _del would be called.=
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 22:24:58 Adam D. Ruppe wrote:
 On Thursday, 24 January 2013 at 21:09:39 UTC, Adam Wilson wrote:
 The problem with  property isn't  property, it's D's
 insistence on optional parens.

No, this isn't a problem; function call syntax has nothing whatsoever to do with property because a property is NOT logically a function!

D's insistance on optional parens _does_ cause problems with functions that return delegates, but property itself isn't really affected by optional parens save for the visual ambiguity caused by optional parens.
 This is so important: a property is supposed to be
 indistinguishable from a data member. That's the fundamental
 definition. It should be fully interchangeable for a plain data
 member.
 
 In other words, as far as the user is concerned, a property *is*
 a data member, NOT a function!
 
 If functions have optional parens, that changes nothing about how
 you access data members.... and since properties are data
 members, it changes absolutely nothing about them either.
 
 If we required data to be accessed with foo->bar and methods to
 be called [foo:bar].... a property would be accessed foo->bar.
 The method syntax is irrelevant.
 
 That the property is implemented with a function call should not
 be known to the user code.

This should probably be emphasized more. A property is an abstraction for a variable and how it's implemented should be irrelevant to the caller. Ideally, it would even be irrelevant whether it's a variable or a property function (though making that the case would require both implementing http://d.puremagic.com/issues/show_bug.cgi?id=8006 and providing a way to mark variables such that they're treated as rvalues rather than lvalues; otherwise, it's still possible to break code when turning a variable into a property function). And we can (and should) implement property in a way that deals with properties properly regardless of what we do with parenless function calls. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 13:48:53 Sean Kelly wrote:
 On Jan 24, 2013, at 1:40 PM, Nathan M. Swan <nathanmswan 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.

What about code that's always ignored property? int delegate() _del; int delegate() getDelegate() { return _del; } auto del = getDelegate(); // does _del get called?

I think a clarification of rule 1 is that parens will be right-associative. So in your example, _del would be called.

I'd argue for simply making it so that the parens are required when a function returns something which is callable. So, getDelegate would be illegal, getDelegate() would return the delegate, and getDelegate()() would call the delegate. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 13:54:09 -0800, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 4:08 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 3:45 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 No, you merely came up with *some* specific cherry-picked examples  
 that
 sparked *some* debate (with most of the disagreing coming from
 you).

I simply mentioned three reasons that came to mind. Andrei

While I don't approve of Mr. Sabalausky's tone or attitude, the crux of his argument is logically sound. The problem with property isn't property, it's D's insistence on optional parens. If paren usage was clearly defined then this would be a non-issue. I would like to point out that I can't think of another systems/general purpose language that has an calling syntax specification as vague and convoluted as D's. C#'s is brutally simple. Java's is brutally simple. In C/C++ everything is a function or field, so, brutally simple. Make D's calling syntax simpler, end optional parens!

Simplicity is clearly good, but there's something to be said about those warts in chained calls. The UFCS-enabled idioms clearly bring a strong argument to the table, there's no ignoring it. Andrei

Then property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 22:04:02 UTC, Andrei Alexandrescu 
wrote:
 Properties are DATA, well except when you need to pass fields 
 by reference etc. at which point the syntactic glue comes 
 unglued.

An enum or a literal can't be passed by reference or otherwise have the address taken either, but we don't argue about if they're data or not, and don't change barely related parts of the language over them. void foo(ref int a) {} int b; foo(b); // ok foo(10); // nope test.d(6): Error: function test.foo (ref int a) is not callable using argument types (int) test.d(6): Error: constant 10 is not an lvalue No big deal. Similarly: enum c = 20; foo(c); test.d(12): Error: function test.foo (ref int a) is not callable using argument types (int) test.d(12): Error: constant 20 is not an lvalue Note: the error message betrays some truth about enum's implementation.... but who cares. And finally: property int bar() { return 0; } foo(bar); test.d(9): Error: function test.foo (ref int a) is not callable using argument types (int) test.d(9): Error: bar() is not an lvalue Like the enum, we see a hint in the error message that the compiler is doing a little magic... but who cares.
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 14:04:02 -0800, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 4:56 PM, Adam Wilson wrote:
 Simplicity is clearly good, but there's something to be said about
 those warts in chained calls. The UFCS-enabled idioms clearly bring a
 strong argument to the table, there's no ignoring it.

 Andrei

Then property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions.

I'm not all that convinced, and it's easy to get wedged into a black vs white position that neglects many subtleties. Properties are DATA, well except when you need to pass fields by reference etc. at which point the syntactic glue comes unglued.

... wat? I fail to see what byref has to do with this. It shouldn't matter what the data is to the compiler as both are built on top of functions, the compiler just enforces different calling syntax for each. If this is a problem for properties then it is a problem for functions to... Because from a compiler POV Data.Property.FieldOfReference; is no different than Data.Function().FieldOfReference; But from a syntax standpoint the difference important because Data.Property(InRef, Count).FieldOfReference; is utterly nonsensical where Data.Function(InRef, Count).FieldOfReference; is perfectly legitimate.
 There's been a lot of strong positions years ago about functions vs.  
 procedures, statements vs. expressions, or even (the glorious 60s!)  
 in-language I/O primitives vs. I/O as library facilities. Successful  
 languages managed to obviate such dichotomies.


 Andrei

-- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent Robert Schadek <realburner gmx.de> writes:
On 01/24/2013 10:56 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 13:54:09 -0800, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 4:08 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 3:45 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 No, you merely came up with *some* specific cherry-picked examples 
 that
 sparked *some* debate (with most of the disagreing coming from
 you).

I simply mentioned three reasons that came to mind. Andrei

While I don't approve of Mr. Sabalausky's tone or attitude, the crux of his argument is logically sound. The problem with property isn't property, it's D's insistence on optional parens. If paren usage was clearly defined then this would be a non-issue. I would like to point out that I can't think of another systems/general purpose language that has an calling syntax specification as vague and convoluted as D's. C#'s is brutally simple. Java's is brutally simple. In C/C++ everything is a function or field, so, brutally simple. Make D's calling syntax simpler, end optional parens!

Simplicity is clearly good, but there's something to be said about those warts in chained calls. The UFCS-enabled idioms clearly bring a strong argument to the table, there's no ignoring it. Andrei

Then property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions.

At while you're at it, just get ride of: int[] a. a.length = 10; That this grows the array stills creeps me out. Robert
Jan 24 2013
prev sibling next sibling parent reply Robert <jfanatiker gmx.at> writes:
Apart from +=, ++, what breaks compatibility of fields and properties,
is that you can't take the address of a property, but of a field (as
already mentioned). To increase compatibility and in order to avoid
breaking peoples' code, when a field is changed to a property, maybe,
simply offer the possibility to declare fields to be a property too,
with  property. And make it so that the access to such a field behaves
exactly the same as to a property: No address taking, and as long as
properties don't support ++, +=, ... maybe even forbid those.

Example:

 property int a;

would be completely equivalent to:

int a_;

 property int a() {
return a_;
}
 property int a(int new_a) {
 a_=new_a;
 return a_;
}

I think this would suffice to make the property concept really sound and
working in practice.

If, this is considered a good thing, I could create yet another property
DIP.

Another thing I am wondering, will this still be possible:

void myProperty(int a)  property {}

void function(int) dg=&myProperty;

Or in other words, will taking the address of a property method still be
possible? I think it would be quite sensible and useful (for e.g.
std.signals), taking the address of a transient return value does not
make any sense anyway, so no ambiguity here. On the other hand it would
break compatibility with fields again. So if we also want to make sure
the way back (from property methods to field) works, disallowing taking
the address might be the way to go for a finally proper implementation. 

To the C# experts: How does C# solve those two issues?

Best regards,

Robert
Jan 24 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 23:26, Robert wrote:
 Apart from +=, ++, what breaks compatibility of fields and properties,
 is that you can't take the address of a property, but of a field (as
 already mentioned). To increase compatibility and in order to avoid
 breaking peoples' code, when a field is changed to a property, maybe,
 simply offer the possibility to declare fields to be a property too,
 with  property. And make it so that the access to such a field behaves
 exactly the same as to a property: No address taking, and as long as
 properties don't support ++, +=, ... maybe even forbid those.

 Example:

  property int a;

 would be completely equivalent to:

 int a_;

  property int a() {
 return a_;
 }
  property int a(int new_a) {
   a_=new_a;
   return a_;
 }

I really like this. Although this is not really what the rest of the thread is about can could perhaps be introduced separately. What I like about this is that I get a virtual property and doesn't have to write the boiler plate code by hand.
 I think this would suffice to make the property concept really sound and
 working in practice.

 If, this is considered a good thing, I could create yet another property
 DIP.

 Another thing I am wondering, will this still be possible:

 void myProperty(int a)  property {}

 void function(int) dg=&myProperty;

 Or in other words, will taking the address of a property method still be
 possible? I think it would be quite sensible and useful (for e.g.
 std.signals), taking the address of a transient return value does not
 make any sense anyway, so no ambiguity here. On the other hand it would
 break compatibility with fields again. So if we also want to make sure
 the way back (from property methods to field) works, disallowing taking
 the address might be the way to go for a finally proper implementation.

 To the C# experts: How does C# solve those two issues?

Scala solves the first one by always implementing public instance variables as virtual functions. -- /Jacob Carlborg
Jan 25 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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" -- /Jacob Carlborg
Jan 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 18:12, Adam Wilson wrote:

  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!

I think this syntax feels quite obvious. -- /Jacob Carlborg
Jan 25 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 14:15:45 -0800, Robert Schadek <realburner gmx.de>  
wrote:

 On 01/24/2013 10:56 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 13:54:09 -0800, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 4:08 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 3:45 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 No, you merely came up with *some* specific cherry-picked examples  
 that
 sparked *some* debate (with most of the disagreing coming from
 you).

I simply mentioned three reasons that came to mind. Andrei

While I don't approve of Mr. Sabalausky's tone or attitude, the crux of his argument is logically sound. The problem with property isn't property, it's D's insistence on optional parens. If paren usage was clearly defined then this would be a non-issue. I would like to point out that I can't think of another systems/general purpose language that has an calling syntax specification as vague and convoluted as D's. C#'s is brutally simple. Java's is brutally simple. In C/C++ everything is a function or field, so, brutally simple. Make D's calling syntax simpler, end optional parens!

Simplicity is clearly good, but there's something to be said about those warts in chained calls. The UFCS-enabled idioms clearly bring a strong argument to the table, there's no ignoring it. Andrei

Then property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions.

At while you're at it, just get ride of: int[] a. a.length = 10; That this grows the array stills creeps me out. Robert

Well, from a syntax standpoint it's legitimate, and D's dynamic arrays are something I prefer over C#'s less flexible solution. My main problem with using it is that D's GC is absurdly naive. When this seemingly benign action causes your program to freeze for non-trivial fractions of a second for the millionth time, it can be quite despair inducing... -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 22:27:02 UTC, Robert wrote:
  property int a;

 would be completely equivalent to: <snip>

Not bad.
 Another thing I am wondering, will this still be possible:

 void myProperty(int a)  property {}

 void function(int) dg=&myProperty;

If I get things my way, no. I'd rewrite that, internally, into &(myProperty()), and then, (unless it returns ref), you'd get an error about can't take address of an rvalue. There'd be no way, under my preference, to treat a property like a function at all.
 I think it would be quite sensible and useful

Indeed, but there's an easy alternative too that works with both kinds of data, properties and regular: wrapping it in an function at the usage site, e.g. "(a) => myProp = a;"
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 14:26:50 -0800, Robert <jfanatiker gmx.at> wrote:

 Apart from +=, ++, what breaks compatibility of fields and properties,
 is that you can't take the address of a property, but of a field (as
 already mentioned). To increase compatibility and in order to avoid
 breaking peoples' code, when a field is changed to a property, maybe,
 simply offer the possibility to declare fields to be a property too,
 with  property. And make it so that the access to such a field behaves
 exactly the same as to a property: No address taking, and as long as
 properties don't support ++, +=, ... maybe even forbid those.

 Example:

  property int a;

 would be completely equivalent to:

 int a_;

  property int a() {
 return a_;
 }
  property int a(int new_a) {
  a_=new_a;
  return a_;
 }

 I think this would suffice to make the property concept really sound and
 working in practice.

 If, this is considered a good thing, I could create yet another property
 DIP.

 Another thing I am wondering, will this still be possible:

 void myProperty(int a)  property {}

 void function(int) dg=&myProperty;

 Or in other words, will taking the address of a property method still be
 possible? I think it would be quite sensible and useful (for e.g.
 std.signals), taking the address of a transient return value does not
 make any sense anyway, so no ambiguity here. On the other hand it would
 break compatibility with fields again. So if we also want to make sure
 the way back (from property methods to field) works, disallowing taking
 the address might be the way to go for a finally proper implementation.

 To the C# experts: How does C# solve those two issues?

 Best regards,

 Robert

Robert, C#'s auto-properties actually do something very close to that. Consider: property int Count { get; set; } A read-write integer property with an automatically implemented getter and setter functions in IL. property int Count { get; } A read-only integer property with an automatically implemented getter function. property int Count { set; } A write-only integer property with an automatically implemented setter function. This is rarely used, but I have seen it. C# then creates an unseen field _CountBacking that is only the IL, not in the user code. The getter/setter then work against this field. This capability was first introduced in C# 3.0 in 2005. The majority of properties are implemented this way in C# care nowadays. 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#. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent reply Robert <jfanatiker gmx.at> writes:
Proper property design:
 
  property int a;
 

 
 int a_;
 
  property int a() {
 return a_;
 }
  property int a(int new_a) {
  a_=new_a;
  return a_;
 }
 

It is guaranteed that they behave the same way and can always be exchanged. -> Taking the address of the getter/setter also always works, enabling things like connecting the setter to a signal for example. I don't know about you guys, but I love this. It is just perfect. What do I miss? Best regards, Robert
Jan 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 23:48, Adam Wilson wrote:

 The syntax provides no way to define read-only or write-only properties.
 Other than that I love it, but I am a biased C# guy.

property(get, set) int a; property(get) int b; property(set) int c; property int d; // same as "a" -- /Jacob Carlborg
Jan 25 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 14:47:44 -0800, Robert <jfanatiker gmx.at> wrote:

 Proper property design:
  property int a;

 int a_;

  property int a() {
 return a_;
 }
  property int a(int new_a) {
  a_=new_a;
  return a_;
 }

It is guaranteed that they behave the same way and can always be exchanged. -> Taking the address of the getter/setter also always works, enabling things like connecting the setter to a signal for example. I don't know about you guys, but I love this. It is just perfect. What do I miss? Best regards, Robert

The syntax provides no way to define read-only or write-only properties. Other than that I love it, but I am a biased C# guy. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
Yeah, I thought of that and the compiler can optimize it away if not
needed. So this would be fine, but see my second, improved proposal.

On Thu, 2013-01-24 at 23:37 +0100, Adam D. Ruppe wrote:
 Indeed, but there's an easy alternative too that works with both 
 kinds of data, properties and regular: wrapping it in an function 
 at the usage site, e.g. "(a) => myProp = a;"

Jan 24 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
There is, just don't do:

 property int a;

but

int a_;

 property int a() { return a_}

-> Omitting the setter. It is a bit more verbose than the C# version,
but adding syntactic sugar later on, if really desired, should not be
too hard.

And thanks for the C# implementation description.


On Thu, 2013-01-24 at 14:48 -0800, Adam Wilson wrote:
 The syntax provides no way to define read-only or write-only
 properties.  
 Other than that I love it, but I am a biased C# guy.

Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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 want to point out another usage of properties that invades my work every day. Consider: public partial class CustomerXAML : DependencyObject { public Guid ID { get { return (Guid)GetValue(IDProperty); } set { SetValue(IDProperty, value); } } public static readonly DependencyProperty IDProperty = DependencyProperty.Register("ID", typeof(Guid), typeof(CustomerXAML), null); } Where: public class DependencyObject { public object GetValue(DependencyProperty prop); public void SetValue(DependencyProperty prop, object value); } What does this code say? I am dealing with data or calling a function? Well to those of you not familiar with WPF/XAML's Dependency pattern let me explain. You're doing both. You see XAML uses something that for lack of a better term I will call a "sparse memory model". Another way to describe it is to say that the DependencyObject stores ONLY the values that have been changed from the default value. They had to do this because their object model is ridiculous and they needed over a gigabyte of RAM just to instantiate all the objects required to draw an empty window. They discovered that most of the values in the object didn't change from the defaults. However, the changes had to be stored in a Dictionary (think Map) for speed, that's what all the typeof's in the Register function are for. And storing/retrieving those directly from the Map would have lead to all sorts of problems. So GetValue/SetValue handle that for you and allows them to do much more, like databinding and update callbacks. My point is this. This does not violate encapsulation, we ARE working with just DATA, but we want to hide the implementation details of HOW we are working with said data, and in this case we CANNOT use a simple backing field. From a user perspective CustomerXAML.ID is JUST data FIELD. But behind the scenes it's a bit more complicated than that. THAT is the power of properties. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
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 just worked through this with Alexander Bothe (of Mono-D fame). Here is what C# does. public Action temp { get; set; } public Action Event { get { return temp; } } t.Event; //returns the delegate t.Event(); //calls the delegate. Simple, clean, clear, concise. No problems with optional parens. (Action is a delegate in C#) -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 6:52 PM, Adam Wilson wrote:
 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 just worked through this with Alexander Bothe (of Mono-D fame). Here is what C# does. public Action temp { get; set; } public Action Event { get { return temp; } } t.Event; //returns the delegate t.Event(); //calls the delegate. Simple, clean, clear, concise. No problems with optional parens. (Action is a delegate in C#)

This looks essentially the same as Walter's proposal. Andrei
Jan 24 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 01:12 AM, Andrei Alexandrescu wrote:
 On 1/24/13 6:52 PM, Adam Wilson wrote:
 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 just worked through this with Alexander Bothe (of Mono-D fame). Here is what C# does. public Action temp { get; set; } public Action Event { get { return temp; } } t.Event; //returns the delegate t.Event(); //calls the delegate. Simple, clean, clear, concise. No problems with optional parens. (Action is a delegate in C#)

This looks essentially the same as Walter's proposal. Andrei

Not at all. Walter's proposal just chooses the other option when stuff is "ambiguous" and adds a hideous special rule in case the empty argument list was obtained from an empty sequence.
Jan 24 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 7:36 PM, Adam Wilson wrote:
 Also non-logical special case rules like this make the language harder
 to learn, therefore harder to evangelize.

Definitely. But it shouldn't be forgotten that syntactic warts are also a liability. Andrei
Jan 24 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 9:54 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 18:00:06 -0800, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 7:36 PM, Adam Wilson wrote:
 Also non-logical special case rules like this make the language harder
 to learn, therefore harder to evangelize.

Definitely. But it shouldn't be forgotten that syntactic warts are also a liability. Andrei

I would argue that given how common they already are, cost of the wart is far smaller than the benefit of not having the unique-to-D special case that makes the language that much harder to learn.

Again, the question needs asking: is it a given that we need to allow optional parentheses? Otherwise we'll keep on rehashing this over and over again. Andrei
Jan 24 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-27 12:20, Michael wrote:
 int CoolThing { in; out; } - auto property without implementation;

 int CoolThing { private in; out; } - private setter; public getter;

 int CoolThing
 {
     in
     {
        _privateCoolThing =  value * 42;
     }

     out
     {
        return 42;
     }
 }

 Explicit calling: void in_CoolThing(int); int out_CoolThing(); Proper
 "Property rewrite" can be implemented.

 Property CoolThing looks like code contract for _privateCoolThing. So
 it's maybe + or -.

 At all, it looks like C# style in D Way.

 --no-parenthesis for current behaviour for non-property functions.

Won't this conflict with contracts, which also uses the "in" and "out" keywords? -- /Jacob Carlborg
Jan 27 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/27/2013 12:35 PM, deadalnix wrote:
 On Sunday, 27 January 2013 at 11:18:01 UTC, sclytrack wrote:
 On Sunday, 27 January 2013 at 10:54:05 UTC, SomeDude wrote:
 On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis wrote:
 I hate optional parentheses with a passion

 - Jonathan M Davis

Same here.

In Delphi they are also optional and nobody uses them. However, everybody else doesn't use them.

Delphi has no real functional capabilities.

What about scala?
Jan 27 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/27/13 8:56 AM, deadalnix wrote:
 On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
 On Sunday, 27 January 2013 at 13:24:31 UTC, TommiT wrote:
 But, joking aside, I think that all hate against optional parentheses
 stems from the increase of ambiguity they indisputably cause.
 However, let's imagine a future where your perfect D IDE paints
 function calls red, and variables blue. Then, it will be obvious to
 you which identifiers are variables and which are function calls
 based on their color. In this situation it will feel silly to have to
 write those empty parentheses, because they don't make the code any
 less ambiguous (it's already perfectly unambiguous because of the
 colors) and, infact, those empty parentheses make the code (a bit)
 harder to read.

If we require clever IDE to distinguish visually something as basic as data semantics and callable semantics it is an indicator language design is screwed. Relying on IDE features is what made Java unusable for expressive, robust code. I may use an IDE help when I need to learn architecture level connections in new project, but at scope level semantics for reader should be perfectly clear and unambiguous even if opened in notepad. 2 cents from vim user and optional parens hater here.

You're being an extremist here. From a vim user and automagic function call hater as well ;) First many reliable code have been written in Java. Quite a lot of it in fact. And refusing IDE help make no real sense. Even vim is an IDE, and not a simple editor.

Language adoption is a complex phenomenon with many variables, and it's easy to neglect certain aspects when assessing the impact of others. Java started as a well-designed language albeit small and underpowered. It enjoyed the benefit of unwavering support from a large corporation and an estimated one billion dollars in marketing budget. (I remember in 1998 non-programming managers in NYC were talking "we must adopt Java!" without even knowing what Java meant. Java may as well be the only programming language in history to enjoy management support before programmer support.) That has caused Java to evolve quite differently from languages with grass-roots support (e.g. C++, Ruby, PHP, or Python). Generally the latter languages grew with little tooling support aside from the traditional Unix toolset, and that is to some extent reflected in the languages themselves. The same goes about C#, which was designed from day 1 assuming resources are available for dedicated tooling support. It would have evolved differently otherwise, and I assume many people would have a dimmer view of either Java or C# if they had to use it with vim and emacs. Andrei
Jan 27 2013
parent Jeff Nowakowski <jeff dilacero.org> writes:
On 01/27/2013 09:26 AM, Andrei Alexandrescu wrote:
 Language adoption is a complex phenomenon with many variables, and it's
 easy to neglect certain aspects when assessing the impact of others.

Indeed it is, as you show below.
 Java started as a well-designed language albeit small and underpowered.
 It enjoyed the benefit of unwavering support from a large corporation
 and an estimated one billion dollars in marketing budget. (I remember in
 1998 non-programming managers in NYC were talking "we must adopt Java!"
 without even knowing what Java meant. Java may as well be the only
 programming language in history to enjoy management support before
 programmer support.)

First off, where do you get this billion dollar marketing figure from? I've seen it from you before, with no citation, and could find no such citation myself when doing a Web search. Second, Java was a "right place, right time" language. It was initially pegged for consumer devices, and was part of a bid to get cable company adoption for a TV add-on device, but when that fell flat it occurred to them the Web was a good fit. It was (in theory, but not in practice -- Flash ended up winning the browser), the hype machine exploded, and the rest is history. For example, if you read this article here: http://vidlar.powweb.com/internett/the-java_net/history.html ...you'll see their growth was fairly organic. Yes, I'm sure they had a marketing budget, but I highly doubt that in 1998 they were spending $1 billion.
 That has caused Java to evolve quite differently from languages with
 grass-roots support (e.g. C++, Ruby, PHP, or Python). Generally the
 latter languages grew with little tooling support aside from the
 traditional Unix toolset, and that is to some extent reflected in the
 languages themselves.

One thing you're missing about Java is that because of it's simplicity of design and static typing, it was so easy to write tools for. No crazy macros or templates, and lots of type information.
 The same goes about C#, which was designed from day 1 assuming resources
 are available for dedicated tooling support. It would have evolved
 differently otherwise, and I assume many people would have a dimmer view
 of either Java or C# if they had to use it with vim and emacs.

That may be true for C#, but in the early days for Java I don't recall an IDE out of the box from Sun. For many it was emacs or whatever, then there was JBuilder (from Borland), and then IBM and IntelliJ, etc.
Jan 27 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 27, 2013 at 04:42:39PM +0100, TommiT wrote:
[...]
 But are you really arguing that: "there can be nothing better than
 plain text for programmers to declare their intent". I wonder why we
 even have graphic operating systems, if graphic elements don't make
 thing easier to use and understand.

I wonder the same thing too. I'm a CLI fanatic. ;-) And in fact, I honestly find GUI's a pain to use, due to their non-scriptability and needless reliance on the rodent. Yes, it makes things more appealing to the eye, but easier to use is arguable (there are too many GUI apps out there that are clearly written by people who have no idea what UI design means), and ease of understanding is also questionable (ever used a GUI app with icons that require clairvoyance to figure out what it means?). Some tasks are more suited for GUI interfaces, like image editing, 3D modelling, etc.. But I find GUIs to be an unnecessary waste of resources on most other tasks. But yes, I know I'm in the minority, and I'm quite OK with that. T -- The trouble with TCP jokes is that it's like hearing the same joke over and over.
Jan 27 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/27/2013 06:33 PM, Dicebot wrote:
 ...
 "unambiguous" == "I can understand semantics of code I have just read
 with as little additional context as possible"
 ...

In order to do that, it is necessary aware of the precise definitions, or at least specifications, of referenced declarations in any case. So by your definition, the current function call syntax is "unambiguous".
Jan 27 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/28/2013 12:34 AM, Timon Gehr wrote:
 On 01/27/2013 06:33 PM, Dicebot wrote:
 ...
 "unambiguous" == "I can understand semantics of code I have just read
 with as little additional context as possible"
 ...

In order to do that, it is necessary

to be
 aware of the precise definitions,
 or at least specifications, of referenced declarations in any case. So
 by your definition, the current function call syntax is "unambiguous".

Jan 27 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/13 11:50 AM, Dicebot wrote:
 On Monday, 28 January 2013 at 16:45:57 UTC, TommiT wrote:
 Do you consider a dynamic arrays' length property to be a good,
 properly designed property:

No.
 And, I don't see much point in having properties that are not allowed
 to have any side-effects.

Then you need something other than properties.

Wait, so you're against any writable properties? Maybe there's a confusion somewhere. Andrei
Jan 28 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-28 18:11, Dicebot wrote:

 Ah, yes, there is a confusion between "side-effect" from the pure
 function point of view and "side-effect" from property functionality
 point of view. I'd say that property setter should be a pure function
 with one exception : it is allowed to changed "this" fields. No global
 state changes, no calls to impure global functions, not even calls to
 "this" non-property functions.

What about getters and setters and gets and sets a value from a cache? -- /Jacob Carlborg
Jan 28 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 28, 2013 at 07:04:21PM +0100, Dicebot wrote:
 On Monday, 28 January 2013 at 17:52:45 UTC, TommiT wrote:
If you think my example of {start_time, end_time, duration}
represents proper use of properties, then I don't see why you
oppose array.length. To me it seems like the same thing. Array has
some length, and you can change it by changing its length
property. T represents a certain time range, and you can change it
by changing any of its three properties {start_time, end_time,
duration} which describe that time range.

T changes its inner encapsulated states. Period. It is no different that properties that calculate result on the fly, like range.empty (which is good property usage). Array.length allocates. Takes from some global resources, takes some considerable time, calls some global allocating function. For me it is a crucial difference that pushes symbol to the world of functions.

In the dinosaur age of Motorola 6502 processors, writing certain values to certain "magic" memory addresses triggers side-effects like switching the console into graphics mode. One could argue this is bad design, but it *is* a precedent for side-effects when assigning values to what can be thought of as "just a variable". By comparison, array.length is pretty tame (no visible side-effects except that the array becomes longer). T -- Life is too short to run proprietary software. -- Bdale Garbee
Jan 28 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 28 January 2013 at 18:10:33 UTC, H. S. Teoh wrote:
 By comparison, array.length is
 pretty tame (no visible side-effects except that the array 
 becomes
 longer).

... *and* possibly relocated in memory, so that it no longer aliases any other slices originally pointing to the same chunk of data. This is the main reason why .length looks far to innocent in my regard - although I don't really feel strongly about the issue. David
Jan 28 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/13 1:04 PM, Dicebot wrote:
 On Monday, 28 January 2013 at 17:52:45 UTC, TommiT wrote:
 If you think my example of {start_time, end_time, duration} represents
 proper use of properties, then I don't see why you oppose
 array.length. To me it seems like the same thing. Array has some
 length, and you can change it by changing its length property. T
 represents a certain time range, and you can change it by changing any
 of its three properties {start_time, end_time, duration} which
 describe that time range.

T changes its inner encapsulated states. Period. It is no different that properties that calculate result on the fly, like range.empty (which is good property usage). Array.length allocates. Takes from some global resources, takes some considerable time, calls some global allocating function. For me it is a crucial difference that pushes symbol to the world of functions.

I guess you hate if people want their bigints to assign with a = b. Andrei
Jan 28 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/13 4:32 PM, Dicebot wrote:
 On Monday, 28 January 2013 at 18:43:19 UTC, Andrei Alexandrescu wrote:
 I guess you hate if people want their bigints to assign with a = b.

Have never used bigints. You mean that copy construction upon assignment allocates too? Yes, I do now like this, too, but see no sane to get around this as it will feel unnatural either way.

So maybe it's time to adjust your preferences.
 Arrays, however, will
 not suffer at all from switching to array.resize(42) syntax from
 array.length = 42 syntax.

Well I think this is a given now. So again - time to adjust preferences :o). Andrei
Jan 28 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/29/13 5:26 AM, Dicebot wrote:
 On Monday, 28 January 2013 at 21:43:25 UTC, Andrei Alexandrescu wrote:
 So maybe it's time to adjust your preferences.

Ye, I know, I speak too much :( Sure, switching to low profile mode.

That's not the right conclusion. Andrei
Jan 29 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/13 3:10 AM, eles wrote:
 On Friday, 25 January 2013 at 00:12:48 UTC, Andrei Alexandrescu wrote:
 On 1/24/13 6:52 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 00:34:42 -0800, Walter Bright
 <newshound2 digitalmars.com> wrote:

This looks essentially the same as Walter's proposal.

You overlook that "get/set" in C# are none other than " property" in D. So, it is nit Walter's proposal, it is property proposal.

Agreed. Andrei
Jan 25 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 01:12, Andrei Alexandrescu wrote:

 public Action temp { get; set; }
 public Action Event { get { return temp; } }
 t.Event; //returns the delegate
 t.Event(); //calls the delegate.

 Simple, clean, clear, concise. No problems with optional parens.

 (Action is a delegate in C#)

This looks essentially the same as Walter's proposal.

This code contains explicit properties. Walter's proposal was to remove the explicit properties. -- /Jacob Carlborg
Jan 25 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Thursday, 24 January 2013 at 22:04:02 UTC, Andrei Alexandrescu 
wrote:
[..]
 There's been a lot of strong positions years ago about 
 functions vs. procedures, statements vs. expressions, or even 
 (the glorious 60s!) in-language I/O primitives vs. I/O as 
 library facilities. Successful languages managed to obviate 
 such dichotomies.


 Andrei

Yeah, back in the day it was a relief to no longer have to decide if I needed to write a function or if I needed to write a procedure. With D, it's been a relief to no longer have to use empty () everywhere. I think we've become stuck in a way of thinking that is creating a lot more complexity than is actually required. For example, I can change my perception of what a variable is and instead view it to be specialized form of function. It has a default implementation and implied storage, which is returned by ref. The compiler can optimize away the need to a real function call. If you take on a view like that, then it may be possible to simplify the language by merging specialized types with alternate syntax into one generalized type with identical syntax. You'll also be forced to implement things in a more consistent and unambiguous way as you proceed along. For example, there has to be different methods for getting the address of the data vs the address of the implementation, and the same solution can work for all types provided that they are treated in the same way. --rt
Jan 24 2013
prev sibling next sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
 1. Empty parens are optional. If there is an ambiguity with the 
 return value taking (), the () go on the return value.

As mentioned, this seems dangerous. I'd suggest requiring when there is ambiguity. It still has generic problems, but it will never be silent.
 4. No more  property.

I'm on the side that would miss optional parens if they died. In would be nice if property actually made a function behave like a field. foo += bar; It seems there are lots of complications around this? So yes kill property. On another note, To properly correct this situation we will break code. So before you get started be sure to try out the new feature preview release approach :)
Jan 24 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 01:42 AM, Adam Wilson wrote:
 ...
 (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.)
 ...

That might explain your bias. I had to work with C# for a project recently, and sometimes experienced a handful C#-induced hiccups when working in other languages. (Furthermore, C# does not have !() brackets into the mix.)
Jan 24 2013
prev sibling next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 01/24/2013 07:34 PM, Jesse Phillips wrote:
 On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
 1. Empty parens are optional. If there is an ambiguity with the return
 value taking (), the () go on the return value.

As mentioned, this seems dangerous. I'd suggest requiring when there is ambiguity. It still has generic problems, but it will never be silent.
 4. No more  property.

I'm on the side that would miss optional parens if they died. In would be nice if property actually made a function behave like a field. foo += bar; It seems there are lots of complications around this? So yes kill property.

This has nothing to do with property. It has to do with defining what += /does/ to a property. I think that what you want is semantic property rewriting. See this: http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semanticrewritingofproperties
 On another note,

 To properly correct this situation we will break code. So before you get
 started be sure to try out the new feature preview release approach :)

Jan 24 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/13 12:17 PM, Rob T wrote:
 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.

I agree with all of the above. There has been a fair amount of rationalization and appeal to emotion on all sides. It would be great to get back to reason and clearly compartmentalize objective arguments (of which there have been a few very profound ones) and personal preference. On the objective side there are a few challenges that have been well discussed: 1. Syntactic and semantic implications of properties that return callable entities 2. Introspection, how does one distinguish between a genuine field and a property when necessary 3. Impact on existing and future code On the subjective side, Walter's and my opinion and experience have been largely aligned. With that in mind but speaking for myself unless otherwise noted, here are some bits of my subjective opinion: 1. In C and C++ the syntax "func" or "object.method" does nothing interesting or useful. In C, "func" is actually equivalent with "&func". In C it's actually worse, "func" yields the type "reference to function" which is highly restricted and obeys some rather arcane rules (in particular it's implicitly convertible to pointer to function). C has no methods so the syntax "object.method" does not apply to it. In C++, "object.method" is probably the oddest construct in the entire language: it returns a type that exists but has no name, is not expressible syntactically, is not first class (one can't assign "object.method" to a variable), and has only two allowed operations: take address or apply the function call operator "()". Various C++ implementations have extensions that fix this. Both Walter and I consider these serious lapses in language design. Two of the most accessible elements of syntax do things of considerably low interest and use. I hope I now clarified why I have a dim view of arguments that - implicitly or explicitly - assume the C or C++ behavior in this area is an example to follow on technical grounds. (Clearly, familiarity is a much better argument.) 2. I have tried to add property appropriately in Phobos, in particular for ranges: struct SomeRange { property bool empty(); property ref T front(); void popFront(); } There's more " property" to be seen with "save" and "back". Subjectively that just didn't work well for me. It adds clutter to an otherwise simple and straightforward API, and penalizes usage for benefits that I could never reap. I understand how some people are glad to put that in everywhere, and find meaning in requiring parens with popFront and popBack but not the others. Yet for me it was liberating (see 1 above too) I could just write "r.popFront" without the parens and have it do its deed. It is the right semantics for a simple syntax. 3. Whatever we do going forward should be _simple_ but not _simplistic_. Right now it's easy to forget that we're all close to the subject. We have it in working memory (at least it's what I think about all the time) and any incremental complexity is an easy cost to absorb intellectually. But when we need to teach this to newcomers or even approach it again with a "cold cache", any undue complexity will be jarring. 4. Whether we like it or not, backward compatibility is an issue. The parens or no parens aspect upon a function call is too ubiquitous to write off as an obscure circumstance. So I don't think the obscurity argument applies. Granted, there are several ways to approach the compatibility issue, all with their specific tradeoffs. All I'm saying is that careful considerations of compatibility must be integral to whatever we do about this. 5. This is a matter in which reasonable people may disagree. For better or worse Walter and to a lesser extent myself are in the position to decide. We're doing the best to gather, mind, and integrate opinions and suggestions but clearly no decision that would please everyone. So please bear with us. I understand this may be frustrating but the best we all can do is think beyond our own preference and on behalf of the larger community. Thanks, Andrei
Jan 25 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/25/2013 2:14 PM, Jonathan M Davis wrote:
 A property function is fundamentally different from a
 normal function by its very nature, not just by its call syntax.

I would have agreed with you on that for years, simply taking its veracity as an axiom, but lately I am not convinced at all of that assertion. I suspect the differences between a property, field, and method are purely contrivance. For example, even accessing a global variable isn't straightforward, if you look under the hood. If it's in a DLL or TLS, there may be a function call in there that is non-trivial.
Jan 25 2013
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:

 For example, even accessing a global variable isn't
 straightforward, if you look under the hood.

Depending on the education under the hood is always a turing machine, Lisp, pseudo code, ... -manfred
Jan 25 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/25/2013 10:06 PM, Mehrdad wrote:
 Walter, that's not how TLS variables are generally implemented in C/C++.

Since I implemented them, I know how they work.
 They're *normal* variables, placed in a special section of the executable,
which
 is automatically switched in and out on every context switch by the OS.

This is not necessarily true at all. It isn't for OSX, for example, and there's nothing in the semantics of TLS which preclude calling a function.
Jan 25 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/25/2013 11:52 PM, Mehrdad wrote:
 The fact that you may have happened to implement something as a function call
 doesn't mean anything with regards to the difference between a function call
and
 a direct access for the _programmer_.

I.e. the difference is purely a contrivance, which was my point.
Jan 26 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-26 08:52, Mehrdad wrote:

 Again, I didn't say they're "necessarily" true either, hence why I
 mentioned Linux and Windows specifically.
 OS X is really the odd one out here, not Windows or Linux.

They can be implemented as a function call on (at least) Linux as well. It's depends on which model is used. Which model is used then depends on various things like who the compiler is able to optimize and dynamic libraries are involved or not. Mac OS X chose the easiest way out and implemented only one mode. A model that works in all cases, and that is a function call. -- /Jacob Carlborg
Jan 26 2013
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
26-Jan-2013 09:04, deadalnix пишет:
 On Friday, 25 January 2013 at 19:59:59 UTC, Andrei Alexandrescu wrote:
 1. Syntactic and semantic implications of properties that return
 callable entities

I don't understand why this is a special case in the first place. It should behave just like a variable of the same type, period.
 C has no methods so the syntax "object.method" does not apply to it.
 In C++, "object.method" is probably the oddest construct in the entire
 language: it returns a type that exists but has no name, is not
 expressible syntactically, is not first class (one can't assign
 "object.method" to a variable), and has only two allowed operations:
 take address or apply the function call operator "()". Various C++
 implementations have extensions that fix this.

 Both Walter and I consider these serious lapses in language design.
 Two of the most accessible elements of syntax do things of
 considerably low interest and use. I hope I now clarified why I have a
 dim view of arguments that - implicitly or explicitly - assume the C
 or C++ behavior in this area is an example to follow on technical
 grounds. (Clearly, familiarity is a much better argument.)

Javascript or C# have solved that issue with C like language nicely. That is why I propose to do the same here (and considering how much C# has been mentioned here, it sound like a serious option). I know that Javascript is a poorly designed language, but on that very specific topic most people agree that was has been done at the time was pure genius. It removes the weird C/C++ object that have no expressible type, and simplify the situation. Additional benefice is that funName now behave the same in all situation, which is also a simplification of the situation.
 2. I have tried to add  property appropriately in Phobos, in
 particular for ranges:

 struct SomeRange {
    property bool empty();
    property ref T front();
   void popFront();
 }

 There's more " property" to be seen with "save" and "back".
 Subjectively that just didn't work well for me. It adds clutter to an
 otherwise simple and straightforward API, and penalizes usage for
 benefits that I could never reap. I understand how some people are
 glad to put that in everywhere, and find meaning in requiring parens
 with popFront and popBack but not the others. Yet for me it was
 liberating (see 1 above too) I could just write "r.popFront" without
 the parens and have it do its deed. It is the right semantics for a
 simple syntax.

If you ask me, I think property have been abused in range design. Many ranges properties really shouldn't be properties. Additionally, this kind of boilerplate can easily be written by automated tools. Java or C# are very verbose, but it is very efficient to write program in them, as the tooling to a great job for you.

Automated tooling is admitting a defeat if we talk about expressive languages. Java was designed with automatic code manipulation in mind and even with todays proliferation of generators it's a pain to work with. TL;DR code is written once and read many times. -- Dmitry Olshansky
Jan 26 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
26-Jan-2013 12:57, deadalnix пишет:
 On Saturday, 26 January 2013 at 08:29:40 UTC, Dmitry Olshansky wrote:
 Automated tooling is admitting a defeat if we talk about expressive
 languages. Java was designed with automatic code manipulation in mind
 and even with todays proliferation of generators it's a pain to work
 with.

 TL;DR code is written once and read many times.

Using tooling is admitting defeat ? That is very misplaced pride (and not even an argument).

There is no pride. Requiring a separate tool to generate code even in simple cases is a defeat. Using tools is fine to refactor, navigate etc. but not to generate "boilerplate" as in the end it still has to be read, modified and fitted with the rest of code. Boilerplate generally has no place in code at all if we can help it.
 And if you think that verbose code is less readable, think twice, or
 follow both links :
 http://code.jquery.com/jquery.js
 http://code.jquery.com/jquery.min.js

 No doubt the less verbose one is more readable !

Obfuscation/minification and boilerplate is not the same. And I bet the second example is the same exact code so you missed the point completely. -- Dmitry Olshansky
Jan 26 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 19:00, Rob T wrote:

 Why was a partial implementation of an experimental half-backed idea
 released into the wild?

It seems just to be how things are done in the D community. Another recent example of this is the UDA that popped up and got implemented from nowhere. -- /Jacob Carlborg
Jan 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-26 17:26, Adam D. Ruppe wrote:

 That design is almost identical to a discussion we had a few months ago
 about it though; the timing was a surprise, but it wasn't bungled the
 way  property was.

Not the syntax. Walter added a two syntaxes one deprecated using brackets and the one we're using now with the at sign and parentheses. -- /Jacob Carlborg
Jan 26 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 16:29:24 -0800, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 01/25/2013 01:12 AM, Andrei Alexandrescu wrote:
 On 1/24/13 6:52 PM, Adam Wilson wrote:
 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 just worked through this with Alexander Bothe (of Mono-D fame). Here is what C# does. public Action temp { get; set; } public Action Event { get { return temp; } } t.Event; //returns the delegate t.Event(); //calls the delegate. Simple, clean, clear, concise. No problems with optional parens. (Action is a delegate in C#)

This looks essentially the same as Walter's proposal. Andrei

Not at all. Walter's proposal just chooses the other option when stuff is "ambiguous" and adds a hideous special rule in case the empty argument list was obtained from an empty sequence.

Basically this. I was writing a longer post that essentially said this. Also non-logical special case rules like this make the language harder to learn, therefore harder to evangelize. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--089e01493bd0c4d50d04d41231b9
Content-Type: text/plain; charset=UTF-8

2013/1/25 Jonathan M Davis <jmdavisProg gmx.com>

 On Thursday, January 24, 2013 22:24:58 Adam D. Ruppe wrote:
 On Thursday, 24 January 2013 at 21:09:39 UTC, Adam Wilson wrote:
 The problem with  property isn't  property, it's D's
 insistence on optional parens.

No, this isn't a problem; function call syntax has nothing whatsoever to do with property because a property is NOT logically a function!

D's insistance on optional parens _does_ cause problems with functions that return delegates, but property itself isn't really affected by optional parens save for the visual ambiguity caused by optional parens.

I think that the "optional parentheses" feature for normal functions should always work in _shallowly_. Even if a function returns some callable object, "optional parentheses" should not applied to the return object recursively. That means: void delegate() foo() { ... } void main() { auto x = foo(); // typeof(x) == void delegate() auto y = foo; // typeof(y) == void delegate() } Kenji Hara --089e01493bd0c4d50d04d41231b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /1/25 Jonathan M Davis <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg = gmx.com" target=3D"_blank">jmdavisProg gmx.com</a>&gt;</span><br><blockquot= e class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bot= tom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,2= 04,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im">On Thursday, January 24, 2013 22:24:58 Adam D. Ruppe wrot= e:<br> &gt; On Thursday, 24 January 2013 at 21:09:39 UTC, Adam Wilson wrote:<br> &gt; &gt; The problem with property isn&#39;t property, it&#39;s D&#39;s<= br> &gt; &gt; insistence on optional parens.<br> &gt;<br> &gt; No, this isn&#39;t a problem; function call syntax has nothing<br> &gt; whatsoever to do with property because a property is NOT<br> &gt; logically a function!<br> <br> </div>D&#39;s insistance on optional parens _does_ cause problems with func= tions that<br> return delegates, but property itself isn&#39;t really affected by optiona= l<br> parens save for the visual ambiguity caused by optional parens.</blockquote=
<div>=C2=A0</div><div>I think that the &quot;optional parentheses&quot; fe=

ction returns some callable object, &quot;optional parentheses&quot; should= not applied to the return object recursively.</div> <div><br></div><div>That means:</div><div>void delegate() foo() { ... }</di= v><div>void main() {</div><div>=C2=A0 auto x =3D foo(); =C2=A0// typeof(x) = =3D=3D void delegate()</div><div>=C2=A0 auto y =3D foo; =C2=A0 =C2=A0// typ= eof(y) =3D=3D=C2=A0void delegate()</div> <div>}</div><div><br></div><div>Kenji Hara</div></div></div></div> --089e01493bd0c4d50d04d41231b9--
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 16:34:44 -0800, Jesse Phillips  
<Jessekphillips+D gmail.com> wrote:

 On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
 1. Empty parens are optional. If there is an ambiguity with the return  
 value taking (), the () go on the return value.

As mentioned, this seems dangerous. I'd suggest requiring when there is ambiguity. It still has generic problems, but it will never be silent.
 4. No more  property.

I'm on the side that would miss optional parens if they died. In would be nice if property actually made a function behave like a field. foo += bar; It seems there are lots of complications around this? So yes kill property. On another note, To properly correct this situation we will break code. So before you get started be sure to try out the new feature preview release approach :)

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. (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.) However, the property issue can be addressed without removing your sides optional parens. Adam Ruppe is working on just such a fix right now. Everyone just needs to relax and take a chill pill (or a shot of whiskey if that's your thing). -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 25 January 2013 at 00:42:09 UTC, kenji hara wrote:
 I think that the "optional parentheses" feature for normal 
 functions should always work in _shallowly_.

I agree. This is the way it makes sense (and the way it is now).
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 25 January 2013 at 00:43:46 UTC, Adam Wilson wrote:
 However, the  property issue can be addressed without removing 
 your sides optional parens. Adam Ruppe is working on just such 
 a fix right now.

Well, not right now - I made progress on it a while ago and hit a snag. Can't work on it now because I'm actually behind schedule on an important work product that is coming up on a deadline in a few weeks. I can waste a few minutes to argue, but a few hours or days to hack dmd is a no go right now.
Jan 24 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 16:47:34 -0800, Adam D. Ruppe  
<destructionator gmail.com> wrote:

 On Friday, 25 January 2013 at 00:43:46 UTC, Adam Wilson wrote:
 However, the  property issue can be addressed without removing your  
 sides optional parens. Adam Ruppe is working on just such a fix right  
 now.

Well, not right now - I made progress on it a while ago and hit a snag. Can't work on it now because I'm actually behind schedule on an important work product that is coming up on a deadline in a few weeks. I can waste a few minutes to argue, but a few hours or days to hack dmd is a no go right now.

I know how that is. No worries. My misunderstanding. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--089e01493bd017332604d4126364
Content-Type: text/plain; charset=UTF-8

I can imagine a situation that we might not want to treat property
functions as DATAs simply.

If you have a struct which have some property functions as members, and
you'd want to serialize it:

struct S {
   int value_;
    property int value() { return value_; }
}

At least, the serialization library should recognize the S.value is a
_property function_, not a int DATA.

In most case, property functions should be treated as a simple DATA field.
but in a few case, it shouldn't. I have thought AddressExpression &func is
one of the places.

Related bugzilla issue I posted:
http://d.puremagic.com/issues/show_bug.cgi?id=9062

Kenji Hara

2013/1/25 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>

 On 1/24/13 4:56 PM, Adam Wilson wrote:

 Simplicity is clearly good, but there's something to be said about
 those warts in chained calls. The UFCS-enabled idioms clearly bring a
 strong argument to the table, there's no ignoring it.

 Andrei

Then property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions.

I'm not all that convinced, and it's easy to get wedged into a black vs white position that neglects many subtleties. Properties are DATA, well except when you need to pass fields by reference etc. at which point the syntactic glue comes unglued. There's been a lot of strong positions years ago about functions vs. procedures, statements vs. expressions, or even (the glorious 60s!) in-language I/O primitives vs. I/O as library facilities. Successful languages managed to obviate such dichotomies. Andrei

--089e01493bd017332604d4126364 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I can imagine a situation that we might not want to treat = property functions as DATAs simply.<div class=3D"gmail_extra"><br></div><di= v class=3D"gmail_extra">If you have a struct which have some property funct= ions as members, and you&#39;d want to serialize it:</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">struct S {<= /div><div class=3D"gmail_extra">=C2=A0 =C2=A0int value_;</div><div class=3D= "gmail_extra">=C2=A0 =C2=A0 property int value() { return value_; }</div><d= iv class=3D"gmail_extra">}</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">At least, t= he serialization library should recognize the S.value is a _property functi= on_, not a int DATA.</div><div class=3D"gmail_extra"><br></div><div class= =3D"gmail_extra"> In most case, property functions should be treated as a simple DATA field. = but in a few case, it shouldn&#39;t. I have thought AddressExpression &amp;= func is one of the places.</div><div class=3D"gmail_extra"><br></div><div c= lass=3D"gmail_extra"> Related bugzilla issue I posted:</div><div class=3D"gmail_extra"><a href=3D= "http://d.puremagic.com/issues/show_bug.cgi?id=3D9062">http://d.puremagic.c= om/issues/show_bug.cgi?id=3D9062</a>=C2=A0<br><br>Kenji Hara</div><div clas= s=3D"gmail_extra"> <br><div class=3D"gmail_quote">2013/1/25 Andrei Alexandrescu <span dir=3D"l= tr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">= SeeWebsiteForEmail erdani.org</a>&gt;</span><br><blockquote class=3D"gmail_= quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-le= ft:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le= ft-style:solid;padding-left:1ex"> <div class=3D"im">On 1/24/13 4:56 PM, Adam Wilson wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote cla= ss=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0= px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20= 4);border-left-style:solid;padding-left:1ex"> Simplicity is clearly good, but there&#39;s something to be said about<br> those warts in chained calls. The UFCS-enabled idioms clearly bring a<br> strong argument to the table, there&#39;s no ignoring it.<br> <br> Andrei<br> </blockquote> <br> Then property needs to be fixed such that optional parens don&#39;t effect= <br> it one way or the other. Removing the concept of properties and making<br> functions that look like properties through optional parens is a very<br> poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA,<br=

for clearly delineating which is which... Properties are not functions.<br> </blockquote> <br></div> I&#39;m not all that convinced, and it&#39;s easy to get wedged into a blac= k vs white position that neglects many subtleties. Properties are DATA, wel= l except when you need to pass fields by reference etc. at which point the = syntactic glue comes unglued.<br> <br> There&#39;s been a lot of strong positions years ago about functions vs. pr= ocedures, statements vs. expressions, or even (the glorious 60s!) in-langua= ge I/O primitives vs. I/O as library facilities. Successful languages manag= ed to obviate such dichotomies.<span class=3D""><font color=3D"#888888"><br=

<br> <br> Andrei<br> </font></span></blockquote></div><br></div></div> --089e01493bd017332604d4126364--
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 10:15:09 kenji hara wrote:
 1. Optional parentheses for normal functions should work shallowly IMO.
 2. Optional parentheses for property functions should not work. Applying ()
 for property function name always applied to its returned value.
 
 #1 is a ratification of current behavior. It allows the combination of UFCS
 and removing redundant ()s.
 #2 is a breaking change. If we need it, community consent is required.

I'd say that we should do both. It's ridiculous to accept parens on property functions, since the whole point is that they be used as if they were variables. They're _supposed_ to be illegal (though -property doesn't check for it right now like it's supposed to - it only checks whether parens are used on non-property functions). So, I don't think that there's any question that #2 needs to happen with property (unless Walter's horrid plan gets put into effect and we lose property entirely). And #1 seems reasonable enough. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 21:06:02 +0100
"mist" <none none.none> wrote:
 
 Not really. Good property usage is somewhat similar to unsafe 
 cast usage - you say to others "Yes, I know what I am doing, 
 please do not pay attention that this data is in fact function". 
 The very point of properties is to be used almost 
 indistinguishable from data and if this usage pattern fails - 
 property author has lied and this is not really a property.
 

+1
 And because of issues like "+=" it is rather difficult (if 
 possible) to define good properties in D now.

+1
Jan 24 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 13:08:08 -0800
"Adam Wilson" <flyboynw gmail.com> wrote:

 On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:
 
 On 1/24/13 3:45 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:
 No, you merely came up with *some* specific cherry-picked examples
 that sparked *some* debate (with most of the disagreing coming from
 you).

I simply mentioned three reasons that came to mind.


And I simply pointed out how they are incorrect.
 
 While I don't approve of Mr. Sabalausky's tone or attitude,

Sorry about that. I'm just frustrated at fighting another uphill D battle against those who have far, far more pull than I do, and are every bit as difficult to sway as I am ;). It's nothing personal against Andrei or Walter or anyone else.
Jan 24 2013
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 25 January 2013 at 01:54:03 UTC, Nick Sabalausky wrote:
 Sorry about that. I'm just frustrated at fighting another 
 uphill D battle against those who have far, far more pull
 than I do, and are every bit as difficult to sway as I am ;).

I literally screamed at my computer screen a couple times in this thread. This is an argument we've been having for years and I've gotta say, I'm kinda fed up with it. But I feel like we're finding common ground this time, where we weren't able to the last several times.
Jan 24 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 27, 2013 at 03:54:54AM +0100, Adam D. Ruppe wrote:
 It would be cool if we could declare variables with anonymous types;
 
 struct { opAssign() {} } foo;

I was thinking we could just use a template to alleviate much of the boilerplate of creating a property using a struct. For example, something like: struct Property(T, alias setter, alias getter) { property T get() { return nullaryFunc!setter(); } alias get this; void opAssign(T val) { return unaryFunc!setter(val); } // ... add other standard stuff like opAssignOp, etc. } Then you could use it like this: struct S { int x, y; Property!(int, ()=>x+y, (int z) { y=z-x; }) derivedProp; } The syntax could do with some improvement, though. Maybe an alias: struct S { alias Property!(int, ()=>x+y, (int z) { y=z-x; }) DerivedProp; int x, y; DerivedProp derivedProp; } S s; s.derivedProp = 123; auto ptr = &s.derivedProp; writeln(*ptr); // etc. T -- Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, / The day and hour soon are coming / When all the IT folks say "Gosh!" / It isn't from a clever lawsuit / That Windowsland will finally fall, / But thousands writing open source code / Like mice who nibble through a wall. -- The Linux-nationale by Greg Baker
Jan 26 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 10:37:51 kenji hara wrote:
 2013/1/25 kenji hara <k.hara.pg gmail.com>
 
 I have thought an additional idea.
 If we really want a feature to disable optional parentheses for normal
 functions, we can add  function attribute to the language spec.
 
 int foo();
  property int bar();
  function int baz(); // new!
 
 int x1 = foo(); // ok
 int x2 = foo; // optional parentheses, allowed
 int y1 = bar(); // disallowed, calling int is meaningless
 int y2 = bar; // ok
 int z1 = baz(); // ok
 int z2 = baz; // *disallowed* by  function attribute

I think calling a function which does not annotated with attribute without parenthesis is legal, Even if a function has some side-effects and a name looks like verb. Because native English grammar does not require parentheses. He runs(). // normal function call He runs. // optional parentheses

Honestly, I don't think that English grammar has anything to do with this. Code isn't English, even if the symbol names chosen are in English. A programming language's grammar should reflect what works best for having a language which is appropriately usable and maintainable. That doesn't necessarily have anything to do with the grammar of any natural language, especially when you consider how different programming language grammars are from those of natural languages. - Jonathan M Davis
Jan 24 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 9:02 PM, Jonathan M Davis wrote:
 On Friday, January 25, 2013 10:37:51 kenji hara wrote:
 2013/1/25 kenji hara<k.hara.pg gmail.com>

 I have thought an additional idea.
 If we really want a feature to disable optional parentheses for normal
 functions, we can add  function attribute to the language spec.

 int foo();
  property int bar();
  function int baz(); // new!

 int x1 = foo(); // ok
 int x2 = foo; // optional parentheses, allowed
 int y1 = bar(); // disallowed, calling int is meaningless
 int y2 = bar; // ok
 int z1 = baz(); // ok
 int z2 = baz; // *disallowed* by  function attribute

I think calling a function which does not annotated with attribute without parenthesis is legal, Even if a function has some side-effects and a name looks like verb. Because native English grammar does not require parentheses. He runs(). // normal function call He runs. // optional parentheses

Honestly, I don't think that English grammar has anything to do with this. Code isn't English, even if the symbol names chosen are in English. A programming language's grammar should reflect what works best for having a language which is appropriately usable and maintainable. That doesn't necessarily have anything to do with the grammar of any natural language, especially when you consider how different programming language grammars are from those of natural languages.

I agree parallels with natural language are tenuous. Anyhow, here's a thought. It is becoming rather clear that one way or another that optional parens are here to stay. So no more need to argue over that - it's just there. Once we consider this a given, the design space is much easier to navigate (which is what Kenji is doing). Andrei
Jan 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 03:19, Andrei Alexandrescu wrote:

 I agree parallels with natural language are tenuous.

No, they're not. Perhaps in this particular case. But code is for humans to be able to read and write. That's why it looks similar to natural languages. Otherwise we would just program in machine code. The computer doesn't really care. -- /Jacob Carlborg
Jan 25 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 22:52:05 +0100
"Jonathan M Davis" <jmdavisProg gmx.com> wrote:
 
 And we can (and should) implement  property in a way that deals with 
 properties properly regardless of what we do with parenless function
 calls.
 

I should clarify that this is my view as well. I may be vocally opposed to optional-parens for function calls, but even I'll admit that *is* a much lesser issue than making sure property stays and is implemented properly.
Jan 24 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--089e01493bd00ded2e04d4136afe
Content-Type: text/plain; charset=UTF-8

2013/1/25 Jonathan M Davis <jmdavisProg gmx.com>

 On Friday, January 25, 2013 10:15:09 kenji hara wrote:
 1. Optional parentheses for normal functions should work shallowly IMO.
 2. Optional parentheses for property functions should not work. Applying

 for property function name always applied to its returned value.

 #1 is a ratification of current behavior. It allows the combination of

 and removing redundant ()s.
 #2 is a breaking change. If we need it, community consent is required.

I'd say that we should do both. It's ridiculous to accept parens on property functions, since the whole point is that they be used as if they were variables. They're _supposed_ to be illegal (though -property doesn't check for it right now like it's supposed to - it only checks whether parens are used on non-property functions). So, I don't think that there's any question that #2 needs to happen with property (unless Walter's horrid plan gets put into effect and we lose property entirely). And #1 seems reasonable enough.

Two months ago, I've tried to implement the rule and posted an experimental pull request. https://github.com/D-Programming-Language/dmd/pull/1311
From that experience, we still need to define some behaviors of corner

One of them is getting an address of property function which returns ref. property ref int foo(); auto x = &foo; // x is a function pointer, or an address of returned value? This is the most sensible problem. (a) If typeof(x) should be a function pointer, we need to use a utility function to get int*. ref identity(T)(ref T t) { return t; } int* p1 = &(identity(foo)); // foo is evaluated to ref int in function argument, // and identity gets through the reference. int* p1 = &foo.identity; // with UFCS, parentheses can be removed. This is a real issue. In phobos, the ref-ness of front property is actually checked in std.range.moveFront. (b) If typeof(x) should be a int*, we will lose the way to getting a function pointer of foo. That is more serious than (a). If we adopt this rule, we will *really* get lost the way to distinguish property functions and raw data fields. (Note that: In current typeof(foo) already returns int. So AddressExp is only one way to getting (normal|property) function information by its type.) From the view of meta-programming, I think this makes a serious flaw. Kenji Hara --089e01493bd00ded2e04d4136afe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /1/25 Jonathan M Davis <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg = gmx.com" target=3D"_blank">jmdavisProg gmx.com</a>&gt;</span><br><blockquot= e class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bot= tom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,2= 04,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im">On Friday, January 25, 2013 10:15:09 kenji hara wrote:<br=

.<br> &gt; 2. Optional parentheses for property functions should not work. Applyi= ng ()<br> &gt; for property function name always applied to its returned value.<br> &gt;<br> &gt; #1 is a ratification of current behavior. It allows the combination of= UFCS<br> &gt; and removing redundant ()s.<br> &gt; #2 is a breaking change. If we need it, community consent is required.= <br> <br> </div>I&#39;d say that we should do both. It&#39;s ridiculous to accept par= ens on property<br> functions, since the whole point is that they be used as if they were<br> variables. They&#39;re _supposed_ to be illegal (though -property doesn&#39= ;t check<br> for it right now like it&#39;s supposed to - it only checks whether parens = are<br> used on non-property functions). So, I don&#39;t think that there&#39;s any= question<br> that #2 needs to happen with property (unless Walter&#39;s horrid plan get= s put<br> into effect and we lose property entirely). And #1 seems reasonable enough= .</blockquote><div><br></div><div>Two months ago, I&#39;ve tried to impleme= nt the rule and posted an experimental pull request.</div><div><a href=3D"h= ttps://github.com/D-Programming-Language/dmd/pull/1311">https://github.com/= D-Programming-Language/dmd/pull/1311</a>=C2=A0<br> </div><div><div><br></div><div>From that experience, we still need to defin= e some behaviors of corner cases, even if the rule is applied.</div></div><= div><br></div><div>One of them is getting an address of property function w= hich returns ref.</div> <div><br></div><div> property ref int foo();</div><div>auto x =3D &amp;foo;= =C2=A0 // x is a function pointer, or an address of returned value?</div><= div><br></div><div>This is the most sensible problem.</div><div>(a) If type= of(x) should be a function pointer, we need to use a utility function to ge= t int*.=C2=A0</div> <div>=C2=A0=C2=A0</div><div>=C2=A0 =C2=A0ref identity(T)(ref T t) { return = t; }</div><div>=C2=A0 =C2=A0int* p1 =3D &amp;(identity(foo));</div><div>=C2= =A0 =C2=A0 =C2=A0=C2=A0// foo is evaluated to ref int in function argument,= </div><div>=C2=A0 =C2=A0 =C2=A0 // and identity gets through the reference.= </div> <div><div>=C2=A0 =C2=A0int* p1 =3D &amp;foo.identity;</div><div>=C2=A0 =C2= =A0 =C2=A0 // with UFCS, parentheses can be removed.</div><div><br></div><d= iv>=C2=A0 =C2=A0This is a real issue. In phobos, the ref-ness of front prop= erty is actually checked in std.range.moveFront.</div> <div><br></div><div>(b) If typeof(x) should be a int*, we will lose the way= to getting a function pointer of foo.</div></div><div>=C2=A0 =C2=A0That is= more serious than (a). If we adopt this rule, we will *really* get lost th= e way to distinguish property functions and raw data fields. (Note that: In= current typeof(foo) already returns int. So AddressExp is only one way to = getting (normal|property) function information by its type.) From the view = of meta-programming, I think this makes a serious flaw.</div> <div><br></div><div>Kenji Hara</div></div></div></div> --089e01493bd00ded2e04d4136afe--
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 21:01:33 Andrei Alexandrescu wrote:
 On 1/24/13 7:41 PM, kenji hara wrote:
 I think that the "optional parentheses" feature for normal functions
 should always work in _shallowly_. Even if a function returns some
 callable object, "optional parentheses" should not applied to the return
 object recursively.
 
 That means:
 void delegate() foo() { ... }
 void main() {
 
 auto x = foo(); // typeof(x) == void delegate()
 auto y = foo; // typeof(y) == void delegate()
 
 }
 
 Kenji Hara

Interesting, so that would mean if anyone ever wants to get the delegate AND call it in one shot would need to write: foo()(). I think this proposal has merit.

I believe that that's what we have now. The problem is when you want a property which returns a delegate. And for that, we need property. Getting rid of property makes it a problem, whereas with property, it can work - as can property functions which return delegates. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--047d7bf10a8604316f04d4138973
Content-Type: text/plain; charset=UTF-8

We can delay the decision about "optional parentheses for normal functions".
It can be separated from "strict prohibition of optional parentheses for
property functions"

Kenji Hara


2013/1/25 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>

 On Thu, 24 Jan 2013 22:52:05 +0100
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote:
 And we can (and should) implement  property in a way that deals with
 properties properly regardless of what we do with parenless function
 calls.

I should clarify that this is my view as well. I may be vocally opposed to optional-parens for function calls, but even I'll admit that *is* a much lesser issue than making sure property stays and is implemented properly.

--047d7bf10a8604316f04d4138973 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">We can delay the decision about &quot;optional parentheses= for normal functions&quot;.<div>It can be separated from &quot;strict proh= ibition of optional parentheses for property functions&quot;</div><div><br> </div><div>Kenji Hara</div></div><div class=3D"gmail_extra"><br><br><div cl= ass=3D"gmail_quote">2013/1/25 Nick Sabalausky <span dir=3D"ltr">&lt;<a href= =3D"mailto:SeeWebsiteToContactMe semitwist.com" target=3D"_blank">SeeWebsit= eToContactMe semitwist.com</a>&gt;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">On Thu, 24 Jan 2013 22:52:05 +0100<br> <div class=3D"im">&quot;Jonathan M Davis&quot; &lt;<a href=3D"mailto:jmdavi= sProg gmx.com">jmdavisProg gmx.com</a>&gt; wrote:<br> &gt;<br> </div><div class=3D"im">&gt; And we can (and should) implement property in= a way that deals with<br> &gt; properties properly regardless of what we do with parenless function<b= r> &gt; calls.<br> &gt;<br> <br> </div>I should clarify that this is my view as well. I may be vocally oppos= ed<br> to optional-parens for function calls, but even I&#39;ll admit that *is* a<= br> much lesser issue than making sure property stays and is implemented<br> properly.<br> <br> </blockquote></div><br></div> --047d7bf10a8604316f04d4138973--
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 25 January 2013 at 02:03:27 UTC, Andrei Alexandrescu 
wrote:
 would Kenji's proposal float your boat?

Yeah, as described in more detail in this post: http://forum.dlang.org/thread/kdqrnl$13ft$1 digitalmars.com?page=16 #1 preserves the status quo (important) #2 is the key result I want from property There's some details I'd still argue, about address of (i say should be the return value), += etc on property (should become setter(getter() + rhs), unless there is no setter, in which case leave it how it is and let it operate on the return value naturally) .... but I'm willing to compromise if we can get these two points: #1: Callable bar(); bar; // must work, returns the callable bar(); // according to rule #1, this also just returns the callable bar()(); // calls the callable #2: property Callable foo(); foo; // just returns the callable foo(); // must call the *Callable*, not just foo And that's what Kenji is talking about, so yes, it is acceptable. The rest is just gravy. BTW I still say the sanest way to implement this is to rewrite foo into (foo()) ASAP. The parens will follow naturally from that, as will references and most everything else. The only hard part after that is to fix up setters, and perhaps clean existing mess out of dmd. But I'm willing to defer to Walter or Kenji's expertise on actually making it happen.
Jan 24 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 25 Jan 2013 02:57:22 +0100
"Adam D. Ruppe" <destructionator gmail.com> wrote:

 On Friday, 25 January 2013 at 01:54:03 UTC, Nick Sabalausky wrote:
 Sorry about that. I'm just frustrated at fighting another 
 uphill D battle against those who have far, far more pull
 than I do, and are every bit as difficult to sway as I am ;).

I literally screamed at my computer screen a couple times in this thread. This is an argument we've been having for years and I've gotta say, I'm kinda fed up with it.

Getting screamed at and just taking it, without ever giving me crap back about it, is one of the top killer features of electronics technology. It's like a squeezy stress ball, except it's always handy when you need it...Probably because it's usually also the cause, but hey.
 But I feel like we're finding common ground this time, where we 
 weren't able to the last several times.

Maybe because we're *all* finally tired of arguing about it ;)
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 21:24:05 Andrei Alexandrescu wrote:
 On 1/24/13 9:11 PM, Jonathan M Davis wrote:
 I believe that that's what we have now. The problem is when you want a
 property which returns a delegate. And for that, we need  property.
 Getting
 rid of  property makes it a problem, whereas with  property, it can work -
 as can property functions which return delegates.

Well how about we just renounce those for the sake of simplification.

Without explicit properties you can't switch back and forth between something being a property function and a variable - which is one of the main points of properties in the first place. With explicit properties, it's possible. Also, I think that there's real value from an API perspective to mark what is and isn't intended to be used as a property. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 18:05:25 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 9:47 AM, Artur Skawina wrote:
 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.

You see, this is the kind of argument that I find very damaging to the conversation. It lacks any shred of material evidence, evokes emotion, manipulates the reader's opinion (framing them into incompetent/inexperienced if they disagree), and implies an appeal to authority. Please don't do that anymore.

Let me rephrase that in a proper way. Functional style is very painful right now. Function you pass as argument are executed implicitly, function as variable don't behave like native ones, and with the new proposal, it add confusion on the function returned. It is kind of dumb that D do not promote functional style as it has shown to solve many problems that arise right now.
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 18:35:08 UTC, mist wrote:
 Yes, I am able to use parens, but in _my_ code I also do not 
 need -property or anything - I am C++ programmer after all, I 
 can discipline myself to certain code style even without 
 compiler help. But writing generic code and reading one of 
 others... I am glad I have not had to do any high-order 
 function generic processing yet.

I always create dumb lambda to do so as going fully functional is too painful map!(a => foo(a)) instead of map!foo . That is really annoying.
Jan 24 2013
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Thu, 24 Jan 2013 18:00:06 -0800, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 7:36 PM, Adam Wilson wrote:
 Also non-logical special case rules like this make the language harder
 to learn, therefore harder to evangelize.

Definitely. But it shouldn't be forgotten that syntactic warts are also a liability. Andrei

I would argue that given how common they already are, cost of the wart is far smaller than the benefit of not having the unique-to-D special case that makes the language that much harder to learn. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 24 2013
parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/27/13 15:11, TommiT wrote:
 There is nothing that says that the source files of X programming language
must be text files. It's just a convention, not a law or a real limitation in
designing languages. Therefore you can't assume that an X source file can be
opened and read with notepad. Someone might design a language that wouldn't
rely on those symbols that just happen to be found on keyboards, but instead,
relied more on text formatting and colors.

Except we're not talking about such hypothetical language, but one where text *is* the natural form for source code. It also happens to be called "D", which means that it will be universally expected to have certain properties. Something can be a great idea in one context, while being an extremely bad one in another. artur
Jan 27 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d043be24015c22104d41414ba
Content-Type: text/plain; charset=UTF-8

2013/1/25 deadalnix <deadalnix gmail.com>

 Functional style is very painful right now. Function you pass as argument
 are executed implicitly, function as variable don't behave like native
 ones, and with the new proposal, it add confusion on the function returned.

I'd like to add a rule which forgotten to mention about optional parentheses for normal functions.
 1. Optional parentheses for normal functions should work shallowly IMO.

getter usage. int foo(); foo(); // ok foo; // ok, from #1 void bar(int); bar(1); // ok bar = 1; // disallowed, from #1a Kenji Hara --f46d043be24015c22104d41414ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /1/25 deadalnix <span dir=3D"ltr">&lt;<a href=3D"mailto:deadalnix gmail.com= " target=3D"_blank">deadalnix gmail.com</a>&gt;</span><br><blockquote class= =3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px= ;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)= ;border-left-style:solid;padding-left:1ex"> Functional style is very painful right now. Function you pass as argument a= re executed implicitly, function as variable don&#39;t behave like native o= nes, and with the new proposal, it add confusion on the function returned.<= br> </blockquote><div><br></div><div>I&#39;d like to add a rule which forgotten= to mention about optional parentheses for normal functions.</div><div><br>= </div><div><div style=3D"font-family:arial,sans-serif;font-size:14px">&gt; = 1. Optional parentheses for normal functions should work shallowly IMO.</di= v> </div><div style=3D"font-family:arial,sans-serif;font-size:14px">1a.=C2=A0O= ptional parentheses for normal functions is just allowed for the getter usa= ge.</div><div style=3D"font-family:arial,sans-serif;font-size:14px"><br></d= iv><div style=3D"font-family:arial,sans-serif;font-size:14px"> int foo();</div><div style=3D"font-family:arial,sans-serif;font-size:14px">= foo(); // ok<br></div><div style=3D"font-family:arial,sans-serif;font-size:= 14px">foo; // ok,=C2=A0 from=C2=A0#1</div><div style=3D"font-family:arial,sans-serif;font-size:14px= "><br></div><div style=3D"font-family:arial,sans-serif;font-size:14px">void= bar(int);<br></div><div style=3D"font-family:arial,sans-serif;font-size:14= px">bar(1); // ok</div> <div style=3D"font-family:arial,sans-serif;font-size:14px">bar =3D 1; =C2= =A0// disallowed, from #1a</div><div style=3D"font-family:arial,sans-serif;= font-size:14px"><br></div><div style=3D"font-family:arial,sans-serif;font-s= ize:14px">Kenji Hara<br> </div></div></div></div> --f46d043be24015c22104d41414ba--
Jan 24 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 11:09:15 kenji hara wrote:
    That is more serious than (a). If we adopt this rule, we will *really*
 get lost the way to distinguish property functions and raw data fields.
 (Note that: In current typeof(foo) already returns int. So AddressExp is
 only one way to getting (normal|property) function information by its
 type.) From the view of meta-programming, I think this makes a serious flaw.

We could add a __trait which detected whether a field was an actual variable or not. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote:
 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.

That is why semantic needs to be clean. Semy hacky stuff ends up causing trouble and we either have to live with it or break code.
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 3:58 PM, mist wrote:
 Really, all this backwards-compatibility talk is a crap.

There's just a lot of evidence that suggests the contrary. Clearly we don't want or like to be conservative, but apparently we need to.

If you or Walter think that D is somehow stable or backward compatible, you must both be very high on drugs. Yes that is an ad hominem. Let me tell you a story. This story take place one month ago. A guy (me) get the news released version of the compiler. After all, he badly needs it as bugs in the previous cause the GC to misbehave in very scary ways. First, some language specs have changed, so his code is broken. But hey, that is to be expected and so the guy fix his code. A bug is discovered in the compiler, it is a regression, and it make the guy's code, once fixed, impossible to compile with 2.061 AT ALL. Hopefully a brave knight (Kenji) cam to fight the monstrous compiler and finally get it to compile the code it should have compiled from day 1. The guy now use a custom patched version of the compiler. No revision of the compiler is released at this point, but worse, the guy's code now trigger some other bugs into 2.061 (but not in his patched version). The guy can't do D on his mac anymore as he have no clue how to do the setup for his patched compiler. After all, he is not really an apple guy. Note that was already using a custom compiler before 2.060 as 2.059 already have blocking bugs for me. D is nothing even remotely close to stable. D introduce breaking change with EVERY new release. Worse, D has no sane way to introduce such breaking change in a sane way. And suddenly, this is an issue ?
Jan 24 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 22:52:36 Andrei Alexandrescu wrote:
 Again, the question needs asking: is it a given that we need to allow
 optional parentheses? Otherwise we'll keep on rehashing this over and
 over again.

I hate optional parentheses with a passion, but I think that it's quite clear that too many people want them (including many who want property) and that too much code will break if we make the change. I think that we can reach a consensus on how property should function, but we'll never get a consensus that optional parentheses should be done away with. So, yes. I think that we can move forward with the assumption that optional parens are here to stay (much as I don't personally like that). - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d04388e1b2816dc04d4159041
Content-Type: text/plain; charset=UTF-8

2013/1/25 Jonathan M Davis <jmdavisProg gmx.com>

 On Friday, January 25, 2013 11:09:15 kenji hara wrote:
    That is more serious than (a). If we adopt this rule, we will *really*
 get lost the way to distinguish property functions and raw data fields.
 (Note that: In current typeof(foo) already returns int. So AddressExp is
 only one way to getting (normal|property) function information by its
 type.) From the view of meta-programming, I think this makes a serious

We could add a __trait which detected whether a field was an actual variable or not.

OK, let's think. When a property function exists: property int foo(); #1 Only check whether it is a property function or not. static assert(__traits(isProperty, foo) == true); Pros: We can get minimum information. Cons: We cannot check whether the foo is other function attributes: pure, nothrow, safe. #2 Returns a type from __traits. static assert(__traits(getPropertyType, foo).stringof == " property int()"); Pros: We can access all information about property function. Cons: __traits() is parsed as an expression, so we cannot use it as a type directly. __traits(getPropertyType, foo)* fp; // declaring function pointer Instead, some template should be required. TypeTuple!(__traits(getPropertyType, foo))[0]* fp; #3 Adding a special case in CastExpression auto fp = &foo; // Not allowed, because property function foo returns an rvalue. auto fp = cast(function)&foo; //New, Gets a function pointer of foo Pros1: Can access fully information of foo from typeof(fp). Pros2: We can call a property function indirectly through function pointer. Pros3: Newly syntax and semantics has no conflict with existings. Cons: cast(function) and cast(delegete) necessary. #4 An extension from #3 auto p = cast( property)&foo; // p is a function pointer. auto p = cast( property)&s.foo; // p is a delegate. Pros: Only one new syntax is necessary. Cons: Ugly... --- In basic, I don't like adding new __traits for this purpose, like #1 and #2. In the compile world of D, a function type is already a first class object to carry the information related function. Similarly, function pointer and delegate are widely used as a runtime container to make runtime bindings to function symbols.
From these facts, creating an escape hatch from property function to normal

reuse a number of meta-programming operations for normal function/function type/function pointers. #3 and #4 are comes from an existing feature, which picking up one from overloaded functions by CastExpression. void foo() {} void foo(int) {} auto fp = cast(void function())&foo; // fp is equal to the address of first foo. So, I prefer adding newly meanings to CastExp. Kenji Hara --f46d04388e1b2816dc04d4159041 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>2013/1/25 Jonathan M Davis <span dir=3D"ltr">&lt;<a h= ref=3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jmdavisProg gmx.com</a=
&gt;</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
<blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px=

r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im">On Friday, January 25, 2013 11:09:15 kenji hara wrote:<br=

will *really*<br> &gt; get lost the way to distinguish property functions and raw data fields= .<br> &gt; (Note that: In current typeof(foo) already returns int. So AddressExp = is<br> &gt; only one way to getting (normal|property) function information by its<= br> &gt; type.) From the view of meta-programming, I think this makes a serious= flaw.<br> <br> </div>We could add a __trait which detected whether a field was an actual v= ariable or<br> not.</blockquote><div><br></div><div>OK, let&#39;s think.</div><div><br></d= iv><div>When a property function exists:</div><div> property int foo();</di= v><div><br></div><div>#1 Only check whether it is a property function or no= t.</div> static assert(__traits(isProperty, foo) =3D=3D true);</div><div class=3D"gm= ail_quote"><div class=3D"gmail_extra">Pros: We can get minimum information.= </div><div class=3D"gmail_extra">Cons: We cannot check whether the foo is o= ther function attributes: pure, nothrow, safe.</div> <div class=3D"gmail_extra"><br><div>#2 Returns a type from __traits.</div>s= tatic assert(__traits(getPropertyType, foo).stringof =3D=3D &quot; property= int()&quot;);</div><div class=3D"gmail_extra">Pros: We can access all info= rmation about property function.</div> <div class=3D"gmail_extra">Cons: __traits() is parsed as an expression, so = we cannot use it as a type directly.</div><div class=3D"gmail_extra">=C2=A0= =C2=A0__traits(getPropertyType, foo)* fp;=E3=80=80=E3=80=80=E3=80=80//=E3= =80=80declaring function pointer</div><div class=3D"gmail_extra"> =C2=A0 =C2=A0Instead, some template should be required.</div><div class=3D"= gmail_extra">=C2=A0 =C2=A0TypeTuple!(__traits(getPropertyType, foo))[0]* fp= ;</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">#3 A= dding a special case in CastExpression</div> <div class=3D"gmail_extra">auto fp =3D &amp;foo; =C2=A0=C2=A0=C2=A0// Not a= llowed, because property function foo returns an rvalue.<br></div><div clas= s=3D"gmail_extra">auto fp =3D cast(function)&amp;foo; =C2=A0 //New, Gets a = function pointer of foo</div> <div class=3D"gmail_extra">Pros1: Can access fully information of foo from = typeof(fp).</div><div class=3D"gmail_extra">Pros2:=C2=A0We can call a prope= rty function=C2=A0indirectly through function pointer.</div><div class=3D"g= mail_extra"> Pros3:=C2=A0Newly syntax and semantics has no conflict with existings.<br><= /div><div class=3D"gmail_extra">Cons: cast(function) and cast(delegete) nec= essary.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra= ">#4 An extension from #3</div> <div class=3D"gmail_extra">auto p =3D cast( property)&amp;foo; =C2=A0// p i= s a function pointer.</div><div class=3D"gmail_extra">auto p =3D cast( prop= erty)&amp;s.foo; =C2=A0// p is a delegate.<br></div><div class=3D"gmail_ext= ra">Pros: Only one new syntax is necessary.</div> <div class=3D"gmail_extra">Cons: Ugly...</div><div class=3D"gmail_extra"><b= r></div><div class=3D"gmail_extra">---</div><div class=3D"gmail_extra"><br = class=3D"">In basic, I don&#39;t like adding new __traits for this purpose,= like #1 and #2.</div> <div class=3D"gmail_extra">In the compile world of D, a function type is al= ready a first class object to carry the information related function. Simil= arly, function pointer and delegate are widely used as a runtime container = to make runtime bindings to function symbols.</div> <div class=3D"gmail_extra">From these facts, creating an escape hatch from = property function to normal function type/pointer=C2=A0is enough worthwhile= to me. It makes it possible to reuse a number of meta-programming operatio= ns for normal function/function type/function pointers.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">#3 and #4 a= re comes from an existing feature, which picking up one from overloaded fun= ctions by CastExpression.</div><div class=3D"gmail_extra">void foo() {}</di= v> <div class=3D"gmail_extra">void foo(int) {}</div><div class=3D"gmail_extra"=
auto fp =3D cast(void function())&amp;foo;=C2=A0<br></div><div class=3D"gm=

mail_extra"> <br></div><div class=3D"gmail_extra">So, I prefer adding newly meanings to = CastExp.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extr= a">Kenji Hara</div></div></div></div> --f46d04388e1b2816dc04d4159041--
Jan 24 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 13:47:31 kenji hara wrote:
 2013/1/25 Jonathan M Davis <jmdavisProg gmx.com>
 
 And actually, something far more important than any of those reasons is
 the
 issue of setters. We've focused most of this discussion on optional parens
 and
 the situation with getter properties, but setter properties and their
 issues
 are also important. Would you want code like this to compile?
 
 range.popFront = 17;
 container.linearRemove = range;
 path.baseName = ".xyz";
 str.icmp = "hello";
 enforce(a == b) = "msg";
 arr.sameHead = arr2;
 
 With  property, we can restrict the functions which can be used with the
 setter syntax to functions where that makes sense. Without it, all kinds
 of
 ridiculous code like the code above would be allowed.
 
 Allowing optional parens is one thing, but conflating that with properties
 is
 something else entirely. Property functions are not just functions which
 are
 called without parens, and we shouldn't act like they are.

I have explained an additional rule in #1a.

I know, and I agree with it. But Andrei is pushing for removing property entirely and looking for arguments to keep it. And IMHO, the issue of how setters are handled is an extremely good reason to keep property. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 00:55:54 UTC, kenji hara wrote:
 I can imagine a situation that we might not want to treat 
 property
 functions as DATAs simply.

 If you have a struct which have some property functions as 
 members, and
 you'd want to serialize it:

 struct S {
    int value_;
     property int value() { return value_; }
 }

 At least, the serialization library should recognize the 
 S.value is a
 _property function_, not a int DATA.

 In most case, property functions should be treated as a simple 
 DATA field.
 but in a few case, it shouldn't. I have thought 
 AddressExpression &func is
 one of the places.

 Related bugzilla issue I posted:
 http://d.puremagic.com/issues/show_bug.cgi?id=9062

Indeed ! property should be different as far as reflection is involved. For usage, it shouldn't make any difference.
Jan 24 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--e89a8f3bae49e632b304d415d64a
Content-Type: text/plain; charset=UTF-8

2013/1/25 Jonathan M Davis <jmdavisProg gmx.com>

 I know, and I agree with it. But Andrei is pushing for removing  property
 entirely and looking for arguments to keep it. And IMHO, the issue of how
 setters are handled is an extremely good reason to keep  property.

I'd like to argue that we should keep property attribute. Kenji Hara --e89a8f3bae49e632b304d415d64a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /1/25 Jonathan M Davis <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg = gmx.com" target=3D"_blank">jmdavisProg gmx.com</a>&gt;</span><br><blockquot= e class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bot= tom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,2= 04,204);border-left-style:solid;padding-left:1ex"> <div class=3D""><div class=3D"h5">I know, and I agree with it. But Andrei i= s pushing for removing property<br></div></div> entirely and looking for arguments to keep it. And IMHO, the issue of how<b= r> setters are handled is an extremely good reason to keep property.</blockqu= ote><div><br></div><div>I&#39;d like to argue that we should keep property= attribute.</div><div>=C2=A0<br></div><div>Kenji Hara</div></div></div></di= v> --e89a8f3bae49e632b304d415d64a--
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 02:24:06 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 9:11 PM, Jonathan M Davis wrote:
 I believe that that's what we have now. The problem is when 
 you want a
 property which returns a delegate. And for that, we need 
  property. Getting
 rid of  property makes it a problem, whereas with  property, 
 it can work - as
 can property functions which return delegates.

Well how about we just renounce those for the sake of simplification.

I don't understand. We want to drop feature that work in other languages and bring benefit, but it is actually impossible to drop a feature that bring many ambiguities for a small syntactic sugar ?
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 03:52:36 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 9:54 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 18:00:06 -0800, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 7:36 PM, Adam Wilson wrote:
 Also non-logical special case rules like this make the 
 language harder
 to learn, therefore harder to evangelize.

Definitely. But it shouldn't be forgotten that syntactic warts are also a liability. Andrei

I would argue that given how common they already are, cost of the wart is far smaller than the benefit of not having the unique-to-D special case that makes the language that much harder to learn.

Again, the question needs asking: is it a given that we need to allow optional parentheses? Otherwise we'll keep on rehashing this over and over again.

It is NOT and workaround have been proposed to solve the UFCS () invasion case, which is probably the only one that don't boil down to lazyness when digging a little.
Jan 24 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 14:35:08 kenji hara wrote:
 2013/1/25 deadalnix <deadalnix gmail.com>
 
  function seems like an extra complication. Ambiguity between setter and
 getter for  properties when UFCS come into play are not solved. Functional
 style is impaired as you can't pass regular function around, just
  function
 . You'll still find trap in generic code around the behavior of regular
 functions.

That's a good point. We need to solve another ambiguity about top-level property function which have a parameter, between top-level property setter and UFCS property getter. module abc; property int foo(int n); void main() { foo = 1; // top-level property setter 1.foo; // property getter with UFCS } We cannot distinguish the two usages without adding any new features.

Well, better that then get rid of property. The other big question is what to do with opDispatch, since unless we add the ability to overload on property with opDispatch, then it can't work with both properties and non-property functions. Maybe opPropDispatch or somesuch could be introduced to solve that particular problem. As for the top-level property problem, we could do something like property(set) / property(get) to distinguish. Or if we don't want the extra complication, we can just leave it. As long as you can use it as both a getter and a setter, it works, even if it still allows for weird uses. It would be nice to have a way to disambiguate it however. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 05:51:44 UTC, Jonathan M Davis 
wrote:
 Well, better that then get rid of  property. The other big 
 question is what to
 do with opDispatch, since unless we add the ability to overload 
 on  property
 with opDispatch, then it can't work with both properties and 
 non-property
 functions. Maybe opPropDispatch or somesuch could be introduced 
 to solve that
 particular problem.

Can you explain the problem you see with opDispatch ?
Jan 24 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 07:14:29 deadalnix wrote:
 On Friday, 25 January 2013 at 05:51:44 UTC, Jonathan M Davis
 
 wrote:
 Well, better that then get rid of  property. The other big
 question is what to
 do with opDispatch, since unless we add the ability to overload
 on  property
 with opDispatch, then it can't work with both properties and
 non-property
 functions. Maybe opPropDispatch or somesuch could be introduced
 to solve that
 particular problem.

Can you explain the problem you see with opDispatch ?

If you make opDispatch property, then you can't use it with normal functions, and if you don't make it property, then it can't be used with property functions. And you can't overload on property, so opDispatch is pretty much screwed with regards to properties at this point. It's certainly fixable, but there will need to be a (small) change in the language to do so. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis 
wrote:
 On Thursday, January 24, 2013 22:52:36 Andrei Alexandrescu 
 wrote:
 I hate optional parentheses with a passion, but I think that 
 it's quite clear
 that too many people want them (including many who want 
  property) and that

I hate the optional parentheses (I really see no point for this except in to!"conversions" but that's templates), I want property to function just like its C# equivalent and I really do not understand why those two issues are so difficult to accept and implement.
Jan 24 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 25 January 2013 at 06:47:30 UTC, eles wrote:
 On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis 
 wrote:
 On Thursday, January 24, 2013 22:52:36 Andrei Alexandrescu 
 wrote:


Seriously, who wants to try criticizing this?: http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx Just provide serious answers why we cannot do that in D.
Jan 24 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 25 January 2013 at 06:54:15 UTC, eles wrote:
 On Friday, 25 January 2013 at 06:47:30 UTC, eles wrote:
 On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis 
 wrote:
 On Thursday, January 24, 2013 22:52:36 Andrei Alexandrescu 
 wrote:



"Properties have many uses: they can validate data before allowing a change; they can transparently expose data on a class where that data is actually retrieved from some other source, such as a database; they can take an action when data is changed, such as raising an event, or changing the value of other fields." I think that having *clear* properties in D is worthing.
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 06:21:59 UTC, Jonathan M Davis 
wrote:
 If you make opDispatch  property, then you can't use it with 
 normal functions,
 and if you don't make it  property, then it can't be used with 
 property
 functions. And you can't overload on  property, so opDispatch 
 is pretty much
 screwed with regards to properties at this point. It's 
 certainly fixable, but
 there will need to be a (small) change in the language to do so.

OK, so opDispatch must definitively be transformed ! I have to say I didn't saw that coming. It isn't that big of a deal if we consider we rewrite that way : a.b => a.opDispatch!"b" a.b!T => a.opDispatch!("b", T) No need for opDispatch to actually be a function. According to what is passed as string, opDispatch can resolve itself as a function or a delegate. See example : class Madness { private void function(Madness)[string] fun; property auto opDispatch(string name)() { immutable f = fun[name]; return { return f(this); }; } } A proper inlining mechanism should handle that.
Jan 24 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 07:47:27 eles wrote:
 On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis
 
 wrote:
 On Thursday, January 24, 2013 22:52:36 Andrei Alexandrescu
 wrote:
 I hate optional parentheses with a passion, but I think that
 it's quite clear
 that too many people want them (including many who want
  property) and that

I hate the optional parentheses (I really see no point for this except in to!"conversions" but that's templates), I want property to function just like its C# equivalent and I really do not understand why those two issues are so difficult to accept and implement.

The issue is that lots of people like optional parentheses. I expect that even if there were no support for properties in the language whatsoever, the folks who like to be able to elide parens would still like that and want it. However, even if we're stuck with parenless function calls being legal, we can still have property function like it does in C# and require that it be used without parens. It's just that many function calls would be able to look like they were getter properties if they're called without parens. But because of the tons of arguments over property (many of them really being over parenless function calls rather than property itself) and the fact that Andrei has never liked the idea of property in the first place, Walter and Andrei seem to be trying to get rid of it and simplify the language - hence this thread. So, we're forced to argue in favor of property. At this point, I think that the best that we can hope for is 1. Parenless function calls will continue to function essentially as they have been. 2. It will be illegal to use a non- property function as a setter. 3. property will be kept, and property functions must be called without parens. If we go that route, we may also be able to make some improvements to property functions to make them closer to how variables are (e.g. make a.prop += 1 valid), and property functions will be able to be essentially as they are in C# as far as functionality goes, but we'll be stuck with parenless function calls. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 25 January 2013 at 00:12:48 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 6:52 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 00:34:42 -0800, Walter Bright
 <newshound2 digitalmars.com> wrote:

This looks essentially the same as Walter's proposal.

You overlook that "get/set" in C# are none other than " property" in D. So, it is nit Walter's proposal, it is property proposal.
Jan 25 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 00:19:28 Walter Bright wrote:
 On 1/24/2013 5:15 PM, kenji hara wrote:
 1. Optional parentheses for normal functions should work shallowly IMO.
 2. Optional parentheses for property functions should not work. Applying
 () for property function name always applied to its returned value.
 
 #1 is a ratification of current behavior. It allows the combination of
 UFCS and removing redundant ()s.
 #2 is a breaking change. If we need it, community consent is required.

There is a way to do #2 without breaking existing code. Create a new property attribute, say, prop. Imbue it with the new behavior. Leave the old property as it is, and let it cycle through the usual warning, deprecation, removal process.

Considering that it's always been the plan that property would be enforced such that any use of it would be illegal with parens (it's explicitly among the things tha TDPL says about property), the expectation of pretty much every D programmer is that that's how property functions are to be used, and it shouldn't come as any surprise when that's enforced. As such, I really don't think that it's a big deal if we simply start enforcing that property functions be called without parens. And if you're really concerned about breakage, then we could start with making it a warning rather than an error. But I wager that in almost all cases, any such warning or error would be triggered by a mistake rather than someone intentially using parens with an property function. - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 25 January 2013 at 07:14:19 UTC, Jonathan M Davis 
wrote:
 On Friday, January 25, 2013 07:47:27 eles wrote:
 On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis

being legal, we can still have property function like it does in C# and require that it be used without parens.

I think the root reason of this fight over what properties are and how are used/usable boils down to the way they are deined in D over C#: 1. in D they are defined as functions (or very similarily to those), so many people are perceiving them as FUNCTIONS to which one tries to stick some variable-like calls 2. in C# they are deined as VARIABLES WITH ACCESSORS, so many people tend to see those as some variables with some extra. IMHO the chosen syntax for defining properties matters in the first place. I do not dear to suggest implementing a more variable-like syntax (like the one in C#), but at least decide once for all which side of the barricade we wand D's properties to be.
Jan 25 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 09:49:00 eles wrote:
 On Friday, 25 January 2013 at 07:14:19 UTC, Jonathan M Davis
 
 wrote:
 On Friday, January 25, 2013 07:47:27 eles wrote:
 On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis

However, even if we're stuck with parenless function calls being legal, we can still have property function like it does in C# and require that it be used without parens.

I think the root reason of this fight over what properties are and how are used/usable boils down to the way they are deined in D over C#: 1. in D they are defined as functions (or very similarily to those), so many people are perceiving them as FUNCTIONS to which one tries to stick some variable-like calls 2. in C# they are deined as VARIABLES WITH ACCESSORS, so many people tend to see those as some variables with some extra. IMHO the chosen syntax for defining properties matters in the first place. I do not dear to suggest implementing a more variable-like syntax (like the one in C#), but at least decide once for all which side of the barricade we wand D's properties to be.

I think that C#'s syntax (or something close to it) probably would have been better, but it's too late now. But a lot of the problem stems from the fact that the original way that properties were implemented in D was essentially what Walter is proposing now, and I believe that the fact that that worked originally was at least partially by accident. So, it's pretty much always been the case in D that properties were implemented via functions, and any change to a syntax similar to C#'s would have been a big change (much as it probably would have been a good idea). - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-03-25 04:01, Manfred Nowak <svv1999 hotmail.com> wrote:

 Nick Treleaven wrote:

 write!"%s\n" = someExpression;

Iff at all I prefer `write!someExpression= "%s\n";' Seriously, checking validity at execution time causes another sort of hiccoughs that should not be part of a language intended for large scale coding.

From what I can see, Nick's solution allows compile time validity checking whereas yours does not. -- Simen
Jan 25 2013
prev sibling next sibling parent "Don" <don nospam.com> writes:
On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote:
 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.

I don't believe that is true. Remember when 'bit' was removed from the language? It didn't cause any complaints at all. This attitude is very harmful. Our real problem is that we're not making promises about what we won't change. When we haven't made such promises, we then become fearful of changing *anything*. Then we bend over backwards to avoid changing things that actually nobody cares about. This is a recipe for locking bugs into the language forever. Instead, we should be trying to continuously expand the things we guarantee will continue to work. Ideally we would be precise about the things that are likely to change, and which we don't currently guarantee.
Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 09:38:27 UTC, Jacob Carlborg wrote:
 On 2013-01-24 22:08, Adam Wilson wrote:

 While I don't approve of Mr. Sabalausky's tone or attitude, 
 the crux of
 his argument is logically sound. The problem with  property 
 isn't
  property, it's D's insistence on optional parens. If paren 
 usage was
 clearly defined then this would be a non-issue. I would like 
 to point
 out that I can't think of another systems/general purpose 
 language that
 has an calling syntax specification as vague and convoluted as 
 D's. C#'s
 is brutally simple. Java's is brutally simple. In C/C++ 
 everything is a
 function or field, so, brutally simple.

 Make D's calling syntax simpler, end optional parens!

There are many languages that allow optional parentheses when calling a function. Ruby, CoffeeScript and Groovy to mention a few.

From what I see on CofeeScript website, it has a VERY different semantic than D on function.
Jan 25 2013
prev sibling next sibling parent Robert burner Schadek <realburner gmx.de> writes:
On 01/24/2013 11:32 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 14:15:45 -0800, Robert Schadek <realburner gmx.de> 
 wrote:

 On 01/24/2013 10:56 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 13:54:09 -0800, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 4:08 PM, Adam Wilson wrote:
 On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 3:45 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 12:51:32 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 No, you merely came up with *some* specific cherry-picked 
 examples that
 sparked *some* debate (with most of the disagreing coming from
 you).

I simply mentioned three reasons that came to mind. Andrei

While I don't approve of Mr. Sabalausky's tone or attitude, the crux of his argument is logically sound. The problem with property isn't property, it's D's insistence on optional parens. If paren usage was clearly defined then this would be a non-issue. I would like to point out that I can't think of another systems/general purpose language that has an calling syntax specification as vague and convoluted as D's. C#'s is brutally simple. Java's is brutally simple. In C/C++ everything is a function or field, so, brutally simple. Make D's calling syntax simpler, end optional parens!

Simplicity is clearly good, but there's something to be said about those warts in chained calls. The UFCS-enabled idioms clearly bring a strong argument to the table, there's no ignoring it. Andrei

Then property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions.

At while you're at it, just get ride of: int[] a. a.length = 10; That this grows the array stills creeps me out. Robert

Well, from a syntax standpoint it's legitimate, and D's dynamic arrays are something I prefer over C#'s less flexible solution. My main problem with using it is that D's GC is absurdly naive. When this seemingly benign action causes your program to freeze for non-trivial fractions of a second for the millionth time, it can be quite despair inducing...

feels strange that assigning a variable resizes a array. Something like a.resize(10) would make me feel better.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Thursday, 24 January 2013 at 22:45:52 UTC, Walter Bright wrote:
 Having a release process does not remove the pain of breaking 
 changes that make users miserable because their older code no 
 longer compiles.

Beg my pardon, it is very ignorant position. It assumes user is some kind of stubborn creature that is scared of any spec changes. But it is not really the case. Users are not afraid of compiler release breaking their code - they are afraid of not having a single compiler version that both is stable enough and works for their code. And that it is very different. It is fine to break code in release if you still provide bug-fixes to some older version that may be recommended for usage until time to fix code base is taken. And this is exactly where good release process shines, it is single most important reason to have it. To sum up my position: 1) D spec is imperfect 2) Breaking change are inevitable 3) Saying "breaking changes" are bad means hiding the problem 4) It is better to focus on process to minimize breaking changes damage than rant about how bad they are 5) Leaving feature badly designed for years with no hope to change is worse than breaking code. I'd really like to read your position on _all_ of those statements, because we are running circles here.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Thursday, 24 January 2013 at 21:23:53 UTC, Andrei Alexandrescu 
wrote:
 ...

Sorry Andrei, with all my due respect, you have a brilliant talent to answer something without actually stating any own position on topic. Please take a look to my answer to Walter: http://forum.dlang.org/post/lpdegnaygbiijuwddgpf forum.dlang.org I'd really like to understand your position too, because arguing about sentences leads nowhere.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 09:49:29 UTC, Don wrote:
 ...

++ It feels that "breaking code" has become some kind of scary ghost that is just being afraid of instead of some kind of analysis-based approach.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
Also I need to remind you that we break code all the time with 
big fixes, literally every release. And end user does not care 
how reasonable breaking it is, they are all the same: time needed 
to update the code base.

We need to admit that breaking is inevitable and go forward from 
there to fix real solvable problems.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 10:26:14 UTC, Robert burner Schadek 
wrote:
 ...
 Yes, the syntax is legit. It's the semantic that "scares" me. 
 IMHO it feels strange that assigning a variable resizes a 
 array. Something like a.resize(10) would make me feel better.

Ye, it was one of the first "Erm wtf?" moments when I started to learn D. And living confirmation that core developers don't really have a strong vision what properties should be.
Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 11:00:34 UTC, Jacob Carlborg wrote:
 On 2013-01-25 01:55, kenji hara wrote:
 I can imagine a situation that we might not want to treat 
 property
 functions as DATAs simply.

 If you have a struct which have some property functions as 
 members, and
 you'd want to serialize it:

 struct S {
    int value_;
     property int value() { return value_; }
 }

 At least, the serialization library should recognize the 
 S.value is a
 _property function_, not a int DATA.

A serialization library would only recognize "value_" since it's an instance variable.

getFields/getProperties/getMethods and you are done. It don't sounds that much of a problem to me.
Jan 25 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 25 January 2013 at 11:01:31 UTC, mist wrote:
 On Friday, 25 January 2013 at 10:26:14 UTC, Robert burner 
 Schadek wrote:
 ...
 Yes, the syntax is legit. It's the semantic that "scares" me. 
 IMHO it feels strange that assigning a variable resizes a 
 array. Something like a.resize(10) would make me feel better.

Ye, it was one of the first "Erm wtf?" moments when I started to learn D. And living confirmation that core developers don't really have a strong vision what properties should be.

I can view *reading* size as a property, but I don't think the setter itself should be a property, since it actually *does* something. Heck, it can throw an exception (!) However, I really think we are way past the point we can change array's interface. I'd just leave it be.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
OK, it has become difficult to follow all thread (newsgroups are 
not that perfect for this), so I will do "tl; dr" in a form of I 
final proposal.

Basic statement 1: Breaking user code is inevitable
Basic statement 2: Special cases are indicators something wrong 
is with design
Basic statement 3: Data is not function. Function is not data. 
(Sorry, John von Neumann!) Property is data.

Proposal itself:
*) -property flag becomes no-op
*) parens for all callables are mandatory
*) parens for properties are prohibited
*) properties are always treated to be of type of their return 
data
*) As a consequence - in UFCS property always behaves as a 
parameter, never as function

Transition issues:
*) Before merging new behavior to master, staging is created from 
last backwards-compatible. Official announcement is made that it 
will be bug-fix supported for at least 6 months.
*) Meta bugzilla issue is created to make Phobos code more strict 
in this regard. Release with new behavior will be allowed to go 
to staging only after this issue is taken care of.
*) All property-related issues that ensure data-like behavior 
like "+=" are marked as preapproved.

And yes, I know that Andrei has already made his decision about 
optional parens and this is also a no-op. But oh well.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
Why? Other than "breaking code".
Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 14:18:06 UTC, Andrei Alexandrescu 
wrote:
 TDPL did exactly that. For example it doesn't mention 
 foreach_reverse or lazy. Far as I know that didn't make a 
 difference.

Wise move !
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Thursday, 24 January 2013 at 13:41:42 UTC, 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.

looks like function pointer variable, why prohibiting to cast this to raw address? &funName is legacy, agree.
 2. funName() call the function.

 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.

cases should be simply an error. And I'd also like to prohibit getters returning void ;)
 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.

not usable with free-from syntax".
 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.

funName(T t ... ) should always behave as t.funName property. It is unnecessary complication.
 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.

return should be disallowed for getters, no ambiguity here and same property suits just fine.
 7a. A function can be defined as both  setter and  getter, and 
 cumulate both behavior.

having both return type and 2 parameters is enough.
 7b.  property is deprecated and redefined as  setter *and* 
  getter for a transitional period.

 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

 9. UFCS without () are delegate like construct :
 10. To allow chain of UFCS calls without () everywhere, an 
 opDispatch is defined in object.d

without (), including (). Profit!
 Waiting for the shitstorm . . .

Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 15:32:13 UTC, mist wrote:
 On Thursday, 24 January 2013 at 13:41:42 UTC, 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.

looks like function pointer variable, why prohibiting to cast this to raw address? &funName is legacy, agree.

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. I played with that using modified version of SDC, and this is clearly what does work best. If you really need an address, you can do : immutable f = function void() {};
 2. funName() call the function.


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

ambiguous cases should be simply an error. And I'd also like to prohibit getters returning void ;)

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. I do agree that a getter returning void is weird, but that wasn't really important here.
 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.

is not usable with free-from syntax".

The above code is rewritten ad funName()(t) . That is why you get that error message. The error message goes out before the compiler has even considered funName was used in a call expression. Your proposal may be an improvement for that very case, but isn't in general the error presented above.
 7a. A function can be defined as both  setter and  getter, and 
 cumulate both behavior.

having both return type and 2 parameters is enough.

7a is required for 7b to work. That is not complication, that is simplification.
 7b.  property is deprecated and redefined as  setter *and* 
  getter for a transitional period.
 9. UFCS without () are delegate like construct :
 10. To allow chain of UFCS calls without () everywhere, an 
 opDispatch is defined in object.d

without (), including (). Profit!

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.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
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.

 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.

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.

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

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.

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.
Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.

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.

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

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.
Jan 25 2013
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
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 */

}
Jan 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 17:37, eles 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 */

 }

One of the points of properties is to have a field with validation. To indicate the validation failed you would throw an exception. Therefore properties need to be able to throw exceptions. -- /Jacob Carlborg
Jan 26 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
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)
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 16:29:40 UTC, deadalnix wrote:
 So you DO make a difference between setters and getters.

 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.
Jan 25 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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
Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.


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.

Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 16:53:43 UTC, deadalnix wrote:
 Because you invalidate most legitimate use of a setter.

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.

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.
Jan 25 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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/
Jan 25 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
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
Jan 25 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 25 January 2013 at 17:17:11 UTC, Rob T wrote:
 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.

The reason property exists in the first place is to fix the edge cases. It got screwed up beyond all recognition by the parenthesis debate, extending its effect well, well beyond the edge case... but that *was* why it was introduced in the first place.
Jan 25 2013
prev sibling next sibling parent "ggeal" <gathDONTnaSPAMgealaich gmail.com> writes:
On Thursday, 24 January 2013 at 22:45:52 UTC, Walter Bright wrote:
 Having a release process does not remove the pain of breaking 
 changes that make users miserable because their older code no 
 longer compiles.

What about providing a tool to automatically perform the transform necessary to fix the code (w.r.t. the breaking change)? That should be feasible in many cases, and there are languages that have gone down this route already (Python 3 partially, Go fully, if I'm not mistaken). gath
Jan 25 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Friday, 25 January 2013 at 17:24:23 UTC, Adam D. Ruppe wrote:
 On Friday, 25 January 2013 at 17:17:11 UTC, Rob T wrote:
 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.

The reason property exists in the first place is to fix the edge cases. It got screwed up beyond all recognition by the parenthesis debate, extending its effect well, well beyond the edge case... but that *was* why it was introduced in the first place.

So historically, the fist implementation of the property concept was through a syntax change, allowing removal of empty parens for the getter and assignment syntax for the setter. But due to edge cases, property was conjured up to solve them through property syntax enforcement. The syntax change was partially implemented without property enforcement leaving it optional, and this brought on the big debate concerning enforcement of parens. Why was a partial implementation of an experimental half-backed idea released into the wild? In the future, we can avoid messes like this through a better design and development process with a little planning behind it. The property feature would have remained in experimental mode until most or all of the debate had been settled, then moved into beta for usage trials, and finally into a production release with no more debate and no more bugs or broken edge cases remaining. --rt
Jan 25 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Friday, 25 January 2013 at 17:52:12 UTC, Dmitry Olshansky 
wrote:
 Instead, we should be trying to continuously expand the things 
 we
 guarantee will continue to work. Ideally we would be precise 
 about the
 things that are likely to change, and which we don't currently 
 guarantee.

+1

I agree with this completely, but we cannot do it until there's a full implementation of a reasonably designed and followed development and release process that includes the language specification. --rt
Jan 25 2013
prev sibling next sibling parent "John T" <no spam.invalid> writes:
Andrei Alexandrescu wrote:
 You made a mistake under the heat of the argument. We all do. 
 Don't try to explain how actually you didn't. The right course 
 is to casually apologize and move on.

At this point, the only difference between you and Nick S. is the frequency of four-letter words in your posts. It's a real pity, D could have been such a nice language, but with that kind of "leadership"... - John
Jan 25 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 25 January 2013 at 18:00:24 UTC, Rob T wrote:
 So historically, the fist implementation of the property 
 concept was through a syntax change, allowing removal of empty 
 parens for the getter and assignment syntax for the setter.

That was actually before my time. The optional parens feature has been in D for as long as I can remember; it was there well before 1.0. But yeah, property was added a few years ago over concerns about a small handful of edge cases.
 Why was a partial implementation of an experimental half-backed 
 idea released into the wild?

This is the reason it is on a compiler switch, -property, instead of the main language. Without -property, the property decoration is ignored. (And with -property, it doesn't do anything useful. The implementation is basically: -property: break my code property: please don't break this code It doesn't fix a single thing, and IIRC the implementor knew it; he just put it in as a first step toward something more complete.)
Jan 25 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 24, 2013 at 12:34:42AM -0800, 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've refrained so far from participating in this thread, but maybe it's time to say something. 1) property and optional parentheses are orthogonal issues. Let's not conflate them and cause more unnecessary confusion in what is already a complex and convoluted discussion. 2) Personally, I don't like leaving out parentheses, but I don't really care either way. In any case, this has nothing to do with property. 3) So, as far as property is concerned, let's forget about optional parentheses or not. 3) property is necessary for good abstraction. Yes, there have been precedents of abuse (like .dup and .idup, which really should *not* be properties but methods), and there are problems in the current implementation of property, but the _concept_ of property itself is a sound one. People have already mentioned the use case of a member variable that needs to be replaced with a getter/setter method. Conceptually speaking, the user of the class should not need to know or care whether it's just a POD field or an abstract entity manipulated by property functions. For example, an Array class has a .length property, and user code should not need to know nor care if this length is an actual size_t field, or something else. All it needs to know is you can get a size_t out of it, and (optionally) change its value (if it's non-const, or if there's a setter method). Sometimes, you get into the situation where it's *possible* to implement a property as a plain old field, but not desirable because of the SSOT (single source of truth) principle. It could be a computed value based on implementation-specific parameters, for example. It would not be nice if you had to store its value, then change code everywhere to make sure that it's always updated when the underlying parameters change. Lots of ugly, unnecessary, inefficient, and fragile code. Therefore, property is necessary. If it causes a problem with the syntax, well, that's a problem with the syntax, not with the concept of property itself. As far as syntax is concerned, it should be very straightforward. Given that the goal of property is to simulate a variable, it should syntactically be identical to a variable, regardless of what it returns. So, given: struct S { property T prop() { ... } } S s; Then: a) Writing s.prop returns a value of type T, for any type T (POD or struct or class or delegate or whatever); b) Writing s.prop() invokes opCall on the *return value* (because .prop behaves exactly as though it were an actual field); c) As a corollary, if T is not callable, then s.prop() is illegal; d) &s.prop returns a pointer to T (if .prop returns a ref). e) As for taking the address of the .prop function itself, my take on it is that (i) from a user's POV, .prop should be indistinguishable from a plain old field, so you shouldn't ever need to do this, and therefore (ii) it's impossible, and (iii) if you *really* need to do it, do this instead: struct S { property T prop() { return this.propImpl(); } // You really only need to know about propImpl if you're // inside S's implementation anyway, so this is private. private T propImpl() { ... } void someMethod() { auto ptr = &propImpl; // There, now you have it. } } f) IOW, .prop cannot be distinguished from an actual field under normal circumstances. If you *really* need to do this (e.g. in serialization code), then use __traits. Consequently: - Assignment syntax like f=g should NOT be treated equivalently to f(g) because conceptually it makes no sense. Writing writeln = "abc"; makes no sense because writeln is not a value that you write to. Writing s.prop = "abc" *does* make sense, because S.prop is a property, and therefore behaves like a variable. Writeln is a function, not a property, so this is illegal. - Syntax like s.prop++ should work automatically (equivalent to s.prop(s.prop+1)), if .prop has both a getter and setter property. It should NOT be allowed for arbitrary methods m just because m has both overloads of m() and m(T). - It's illegal to mark a function that takes 2 or more arguments as property, because it makes no sense. The bottom line is, if you mark a function as property, then it should behave as if it were a variable of its return type. This has nothing to do with optional parentheses or not, and assignment syntax should be reserved for variables (and by extension property, because property means something behaves like a variable), not arbitrary functions. T -- What are you when you run out of Monet? Baroque.
Jan 25 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
25-Jan-2013 22:39, H. S. Teoh пишет:
 On Thu, Jan 24, 2013 at 12:34:42AM -0800, 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've refrained so far from participating in this thread, but maybe it's time to say something. 1) property and optional parentheses are orthogonal issues. Let's not conflate them and cause more unnecessary confusion in what is already a complex and convoluted discussion. 2) Personally, I don't like leaving out parentheses, but I don't really care either way. In any case, this has nothing to do with property. 3) So, as far as property is concerned, let's forget about optional parentheses or not. 3) property is necessary for good abstraction. Yes, there have been precedents of abuse (like .dup and .idup, which really should *not* be properties but methods), and there are problems in the current implementation of property, but the _concept_ of property itself is a sound one. People have already mentioned the use case of a member variable that needs to be replaced with a getter/setter method. Conceptually speaking, the user of the class should not need to know or care whether it's just a POD field or an abstract entity manipulated by property functions. For example, an Array class has a .length property, and user code should not need to know nor care if this length is an actual size_t field, or something else. All it needs to know is you can get a size_t out of it, and (optionally) change its value (if it's non-const, or if there's a setter method). Sometimes, you get into the situation where it's *possible* to implement a property as a plain old field, but not desirable because of the SSOT (single source of truth) principle. It could be a computed value based on implementation-specific parameters, for example. It would not be nice if you had to store its value, then change code everywhere to make sure that it's always updated when the underlying parameters change. Lots of ugly, unnecessary, inefficient, and fragile code. Therefore, property is necessary. If it causes a problem with the syntax, well, that's a problem with the syntax, not with the concept of property itself. As far as syntax is concerned, it should be very straightforward. Given that the goal of property is to simulate a variable, it should syntactically be identical to a variable, regardless of what it returns. So, given: struct S { property T prop() { ... } } S s; Then: a) Writing s.prop returns a value of type T, for any type T (POD or struct or class or delegate or whatever); b) Writing s.prop() invokes opCall on the *return value* (because .prop behaves exactly as though it were an actual field); c) As a corollary, if T is not callable, then s.prop() is illegal; d) &s.prop returns a pointer to T (if .prop returns a ref). e) As for taking the address of the .prop function itself, my take on it is that (i) from a user's POV, .prop should be indistinguishable from a plain old field, so you shouldn't ever need to do this, and therefore (ii) it's impossible, and (iii) if you *really* need to do it, do this instead: struct S { property T prop() { return this.propImpl(); } // You really only need to know about propImpl if you're // inside S's implementation anyway, so this is private. private T propImpl() { ... } void someMethod() { auto ptr = &propImpl; // There, now you have it. } } f) IOW, .prop cannot be distinguished from an actual field under normal circumstances. If you *really* need to do this (e.g. in serialization code), then use __traits. Consequently: - Assignment syntax like f=g should NOT be treated equivalently to f(g) because conceptually it makes no sense. Writing writeln = "abc"; makes no sense because writeln is not a value that you write to. Writing s.prop = "abc" *does* make sense, because S.prop is a property, and therefore behaves like a variable. Writeln is a function, not a property, so this is illegal. - Syntax like s.prop++ should work automatically (equivalent to s.prop(s.prop+1)), if .prop has both a getter and setter property. It should NOT be allowed for arbitrary methods m just because m has both overloads of m() and m(T). - It's illegal to mark a function that takes 2 or more arguments as property, because it makes no sense. The bottom line is, if you mark a function as property, then it should behave as if it were a variable of its return type. This has nothing to do with optional parentheses or not, and assignment syntax should be reserved for variables (and by extension property, because property means something behaves like a variable), not arbitrary functions. T

Good summary of what property should do. Let's just not forget that works like plain variable must clearly tackle contexts such as: a.b.c.d = xyz; //where b, c, d are properties And things like: a.prop += qwerty; I can see how it must work from your proposal but listing some "canonical" re-writes won't hurt. -- Dmitry Olshansky
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 18:41:46 UTC, H. S. Teoh wrote:
 ...

Sound base that avoid discussion of controversial topics :) Looks like I can agree with almost everything. Probably even everything. Only thing that needs to be defined is property on free-functions: disallow, treat as global variable or treat as an extension methods. We has small discussion on this topic with deadalanix afair somewhere up the topic.
Jan 25 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 12:24:56 monarch_dodra wrote:
 On Friday, 25 January 2013 at 11:01:31 UTC, mist wrote:
 On Friday, 25 January 2013 at 10:26:14 UTC, Robert burner
 
 Schadek wrote:
 ...
 Yes, the syntax is legit. It's the semantic that "scares" me.
 IMHO it feels strange that assigning a variable resizes a
 array. Something like a.resize(10) would make me feel better.

Ye, it was one of the first "Erm wtf?" moments when I started to learn D. And living confirmation that core developers don't really have a strong vision what properties should be.

I can view *reading* size as a property, but I don't think the setter itself should be a property, since it actually *does* something. Heck, it can throw an exception (!)

So? Of course, setters can throw exceptions. Why wouldn't they be able to? For instance, if you try and set the hour on a TimeOfDay to 25, it's going to throw a DateTimeException. I could see an argument that the operations that length does when set are expensive enough that it shouldn't be a setter property, but setters are not necessarily going to be as simple as setting a variable, and throwing exceptions from them is normal, depending on what they need to do. I could see generally restricting them to operations which are O(1) or O(log n) rather than O(n) or worse (and I think that C#'s guidelines on properties say something along those lines), but you make it sound as if all a setter property should ever do is simply set a variable, and if that were the case, you might as well just make it a public variable.
 However, I really think we are way past the point we can change
 array's interface. I'd just leave it be.

It's far too late at this point. I don't know if it was a good design choice or not (and I rarely use it myself), but it's not going to change. - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Fri, 25 Jan 2013 10:39:50 -0800, H. S. Teoh <hsteoh quickfur.ath.cx>  
wrote:

 On Thu, Jan 24, 2013 at 12:34:42AM -0800, 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've refrained so far from participating in this thread, but maybe it's time to say something. 1) property and optional parentheses are orthogonal issues. Let's not conflate them and cause more unnecessary confusion in what is already a complex and convoluted discussion. 2) Personally, I don't like leaving out parentheses, but I don't really care either way. In any case, this has nothing to do with property. 3) So, as far as property is concerned, let's forget about optional parentheses or not. 3) property is necessary for good abstraction. Yes, there have been precedents of abuse (like .dup and .idup, which really should *not* be properties but methods), and there are problems in the current implementation of property, but the _concept_ of property itself is a sound one. People have already mentioned the use case of a member variable that needs to be replaced with a getter/setter method. Conceptually speaking, the user of the class should not need to know or care whether it's just a POD field or an abstract entity manipulated by property functions. For example, an Array class has a .length property, and user code should not need to know nor care if this length is an actual size_t field, or something else. All it needs to know is you can get a size_t out of it, and (optionally) change its value (if it's non-const, or if there's a setter method). Sometimes, you get into the situation where it's *possible* to implement a property as a plain old field, but not desirable because of the SSOT (single source of truth) principle. It could be a computed value based on implementation-specific parameters, for example. It would not be nice if you had to store its value, then change code everywhere to make sure that it's always updated when the underlying parameters change. Lots of ugly, unnecessary, inefficient, and fragile code. Therefore, property is necessary. If it causes a problem with the syntax, well, that's a problem with the syntax, not with the concept of property itself. As far as syntax is concerned, it should be very straightforward. Given that the goal of property is to simulate a variable, it should syntactically be identical to a variable, regardless of what it returns. So, given: struct S { property T prop() { ... } } S s; Then: a) Writing s.prop returns a value of type T, for any type T (POD or struct or class or delegate or whatever); b) Writing s.prop() invokes opCall on the *return value* (because .prop behaves exactly as though it were an actual field); c) As a corollary, if T is not callable, then s.prop() is illegal; d) &s.prop returns a pointer to T (if .prop returns a ref). e) As for taking the address of the .prop function itself, my take on it is that (i) from a user's POV, .prop should be indistinguishable from a plain old field, so you shouldn't ever need to do this, and therefore (ii) it's impossible, and (iii) if you *really* need to do it, do this instead: struct S { property T prop() { return this.propImpl(); } // You really only need to know about propImpl if you're // inside S's implementation anyway, so this is private. private T propImpl() { ... } void someMethod() { auto ptr = &propImpl; // There, now you have it. } } f) IOW, .prop cannot be distinguished from an actual field under normal circumstances. If you *really* need to do this (e.g. in serialization code), then use __traits. Consequently: - Assignment syntax like f=g should NOT be treated equivalently to f(g) because conceptually it makes no sense. Writing writeln = "abc"; makes no sense because writeln is not a value that you write to. Writing s.prop = "abc" *does* make sense, because S.prop is a property, and therefore behaves like a variable. Writeln is a function, not a property, so this is illegal. - Syntax like s.prop++ should work automatically (equivalent to s.prop(s.prop+1)), if .prop has both a getter and setter property. It should NOT be allowed for arbitrary methods m just because m has both overloads of m() and m(T). - It's illegal to mark a function that takes 2 or more arguments as property, because it makes no sense. The bottom line is, if you mark a function as property, then it should behave as if it were a variable of its return type. This has nothing to do with optional parentheses or not, and assignment syntax should be reserved for variables (and by extension property, because property means something behaves like a variable), not arbitrary functions. T

++ -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 25 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 22:09:18 Dmitry Olshansky wrote:
 25-Jan-2013 02:32, Adam D. Ruppe пишет:
 On Thursday, 24 January 2013 at 22:28:04 UTC, Jonathan M Davis wrote:
 However, I do think that would be able to mark variables such that
 they're treated as rvalues such that swapping a
 variable out with a property function dosen't break code


IMHO this is a critical part of what a property should do - transparently swapping fields with some functional accessors.

And for that, we need to keep property. It's impossible without explicit properties (though there are obviously some improvements that we have to make in order to make it work properly with property). - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 19:51:53 mist wrote:
 On Friday, 25 January 2013 at 18:41:46 UTC, H. S. Teoh wrote:
 ...

Sound base that avoid discussion of controversial topics :) Looks like I can agree with almost everything. Probably even everything. Only thing that needs to be defined is property on free-functions: disallow, treat as global variable or treat as an extension methods. We has small discussion on this topic with deadalanix afair somewhere up the topic.

So, you're arguing that property shouldn't be usable on anything but member functions? We've had discussions on that in the past, and most everyone agreed that it should be legal to use property on module-level variables, and I've never heard anyone try to argue before that it shouldn't work with UFCS (which is what I assume you mean by extension methods - I don't know what else you would mean). There's an ambiguity problem that needs to be solved with free functions where in some cases, you can't properly distinguish between whether it's supposed to be a getter or a setter, but that can be fixed (e.g. property(get) and property(set)), but I think that if you're going to argue that something like bool exists(string filename) {...} if(filename.exists) or S globalVar() {...} if(globalVar == blah) shouldn't work, then you're fighting a losing battle. An both of those idioms are used in Phobos. I agree that calling it a property is a little silly when it's a module-level variable, since there's no object for it to be a property of, but really, property is an abstraction for variables in general, not just member variables. - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 10:39:50 H. S. Teoh wrote:
 I've refrained so far from participating in this thread, but maybe it's
 time to say something.

I agree with pretty much everything that you said, and it's exactly why we need explicit properties. So, we need to keep property and make whatever adjustments are necessary in order to make it function like a variable would to the point that you can swap out variables and property functions without breaking code (though that will probably mean allowing something like marking variables with property to make them be treated as rvalues rather than just improving the handling of property functions). - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 17:37:48 eles 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 */
 
 }

And why wouldn't setters be able to throw. Why on earth would you do other than throw in code like you have above? How on earth would a setter report a bad argument if it was forced to be nothrow? Exceptions are the correct solution. Setters _need_ to be able to throw. Plenty of them don't need to, but plenty of them do. For instance, many of the properties in std.datetime will throw if you give them invalid values (like setting the hour to 28). I don't see how you could possibly argue that a setter should not be able to throw. - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 25 January 2013 at 19:30:41 UTC, Jonathan M Davis 
wrote:
 On Friday, January 25, 2013 17:37:48 eles wrote:
 On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright

you do other than throw in code like you have above? How on earth would a setter report a bad argument if it was forced to be nothrow? Exceptions are the correct solution. Setters _need_ to be able to throw. Plenty of them don't need to, but plenty of them do. For instance, many of the properties in std.datetime will throw if you give them invalid values (like setting the hour to 28). I don't see how you could possibly argue that a setter should not be able to throw.

You are right. In fact, just after I post the message, I was hit by second toughts. But a issue still remains: assignments of variables are not usually checked for exceptions. Programmers do not have in mind that they could trigger exceptions. However, properties could do. The danger that I see is that programmers will start to "preventively" check everything for exceptions, "just in case" that those current variable assignments would be latter turned into properties. Do you feel like embracing all your code in try/catch?
Jan 25 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 25 Jan 2013 02:39:15 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/25/13 2:12 AM, Artur Skawina wrote:
 On 01/24/13 21:13, Andrei Alexandrescu wrote:
 On 1/24/13 2:03 PM, Artur Skawina wrote:
 Trying to make arguments you don't like go away and silencing the
 messenger is your MO.

Now that's what's called "ad hominem".

No, it's not - it's just stating the facts; this was not the first such incident.

Of course it is. The definition is simple enough, e.g. from Wikipedia: An ad hominem (Latin for "to the man"), short for argumentum ad hominem, is an argument made personally against an opponent instead of against their argument.

"Ad hominem" *as a logical fallacy* is only applicable when the argument against the person is *intended* to prove something unrelated to the targeted person. For example, "Joe Schmo is a known asshole" *could* very easily be a logical fallacy. But it clearly *isn't* a fallacy if the speaker is using it to show: "Joe Schmo, your request to be a kindergarten teacher should be rejected." Artur was clearly making a side note about an unfortunate tendency in some of your posts that I've noticed as well. This was to make you aware of it and hopefully do it less. It was NOT, as you suggest, being put forth as evidence for Artur's property-related arguments.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 19:30:26 UTC, Jonathan M Davis 
wrote:
 ...

I am not going to argue anything, I am just asking _how_ they are supposed to work, what are exact semantic. I have added various syntax cases to wiki: http://wiki.dlang.org/Property_Discussion_Wrap-up#.40property_on_free_functions What I am going to argue is if all of those example are supposed to work. We can't define property semantics to be "just like data" when property symbol can't be just interchanged with data symbol. From the syntax point of view no issues there.
Jan 25 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 25 January 2013 at 16:48:21 UTC, Simen Kjaeraas wrote:
 On 2013-37-25 17:01, eles <eles eles.com> wrote:

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

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.

See this answer here: http://forum.dlang.org/post/mdhvjbjqryzjljzqleay forum.dlang.org The problem is that programmers would start feeling like "it's better" to check every assignment for exceptions, in the case that the variable is latter converted into a throwing property. I have no solution to that, though... OOH, I feel it will lead to bad programming style. OTOH, I feel like masking a database interrogation behind a property will throw some exception sooner or later. So, I am clueless.
Jan 25 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 25 Jan 2013 15:29:21 +0100
"mist" <none none.none> wrote:

 On Friday, 25 January 2013 at 14:18:43 UTC, TommiT wrote:
 I don't see 1.foo the way you see it. I see it like this:

  property bool is_zero(X value)
 {
     return value == 0;
 }

 void main()
 {
     X value;
     value.is_zero;
 }

 It's just that X happens to be a built-in type, instead of a 
 user-defined type. But I don't see why should that matter.

It is a tempting attempt to save two symbols of typing that completely breaks property semantics. I am objecting against it. With all my passion. Use value.is_zero() for UFCS magic.

I think you might have misunderstood it. What he's trying to do is use UFCS to add a property to a type instead of adding a function.
Jan 25 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 20:41:01 eles wrote:

 You are right. In fact, just after I post the message, I was hit
 by second toughts.
 
 But a issue still remains: assignments of variables are not
 usually checked for exceptions. Programmers do not have in mind
 that they could trigger exceptions.
 
 However, properties could do.
 
 The danger that I see is that programmers will start to
 "preventively" check everything for exceptions, "just in case"
 that those current variable assignments would be latter turned
 into properties.
 
 Do you feel like embracing all your code in try/catch?

Except that variable assignments _can_ throw, because opAssign could throw. It's true that replacing a variable with a property function which checks its arguments would likely add a new exception to catch, but there's really no way around that. But if the property function checks for stuff which was supposed to be valid before, you changed the semantics anyway, which could be done in a variety of other ways (e.g. making the property function multiply the argument by 7). The reality of the matter is that a property function _isn't_ a variable, just like an overloaded operator isn't the same as using that operator on a built-in type. And the issues are pretty much the same as they are with overloaded operators. But what should be done with try-catch blocks depends on what the code's doing, and if you're having to litter your code with them, you're probably doing something wrong anyway. Still, the possible breakage caused by replacing a variable with a property function which throws is the sort of thing that needs to be considered when making that change. - Jonathan m Davis
Jan 25 2013
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Fri, Jan 25, 2013 at 4:47 AM, Manfred Nowak <svv1999 hotmail.com> wrote:
 Philippe Sigaud wrote:

 cwritefln!"For sample

Cough! `cfln' would eliminate the five letters `write'. For which purpose are they needed?

:) Yes, I agree.
 Seriously, without some guarentee that `!"' starts a compile time
 checked string---and a defined metalanguage for describing compile
 time checking of compile time checked strings---close to every
 coding project will become an unmaintanable mess of DSL
 implementations "on the fly".

Well, the string-formatting DSL is well known. I don't think someone would be that distressed by its use.
 The code you supplied on pages 170 to 171 is a good example for
 this forsight: please declare how much time an average member of
 an intended group of maintenance coders will need to grab the
 content of your idea. And of course declare the minimal skills all
 members of this group must have.

Such hate... Keep cool and please give us your own code and preferred solution to compile-time formatting string checking.
Jan 25 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Friday, 25 January 2013 at 19:50:23 UTC, eles wrote:
 On Friday, 25 January 2013 at 16:48:21 UTC, Simen Kjaeraas 
 wrote:
 On 2013-37-25 17:01, eles <eles eles.com> wrote:

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

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.

See this answer here: http://forum.dlang.org/post/mdhvjbjqryzjljzqleay forum.dlang.org The problem is that programmers would start feeling like "it's better" to check every assignment for exceptions, in the case that the variable is latter converted into a throwing property. I have no solution to that, though... OOH, I feel it will lead to bad programming style. OTOH, I feel like masking a database interrogation behind a property will throw some exception sooner or later. So, I am clueless.

You can easily wrap all of your functions in a try catch block that will act as a safety net and catch all potential Exception throws. Unfortunately I don't know if there's a performance hit with wrapping up all functions in this way. --rt
Jan 25 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Jan 2013 10:39:50 -0800
schrieb "H. S. Teoh" <hsteoh quickfur.ath.cx>:


 - It's illegal to mark a function that takes 2 or more arguments as
    property, because it makes no sense.
 

3 or more arguments. UFCS properties have 2 arguments: property void age(Person p, int value); //OK, bad example, but you get the idea
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
Finally, stating some opinions clearly.
Thank you.
Jan 25 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 25 Jan 2013 02:57:22 +0100
"Adam D. Ruppe" <destructionator gmail.com> wrote:

 On Friday, 25 January 2013 at 01:54:03 UTC, Nick Sabalausky wrote:
 Sorry about that. I'm just frustrated at fighting another 
 uphill D battle against those who have far, far more pull
 than I do, and are every bit as difficult to sway as I am ;).

I literally screamed at my computer screen a couple times in this thread. This is an argument we've been having for years and I've gotta say, I'm kinda fed up with it.

What really got me upset about it was that here we have one of my favorite modern language features, properties, and then all of a sudden *both* the top #1 and #2 people behind D start trying to gut it if not outright remove it from the language entirely, instead of enacting, or at least promising to *eventually* enact, the long overdue fixes I've been anxiously awaiting.
Jan 25 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 25, 2013 at 08:46:51PM +0100, mist wrote:
 On Friday, 25 January 2013 at 19:30:26 UTC, Jonathan M Davis wrote:
...

I am not going to argue anything, I am just asking _how_ they are supposed to work, what are exact semantic. I have added various syntax cases to wiki: http://wiki.dlang.org/Property_Discussion_Wrap-up#.40property_on_free_functions What I am going to argue is if all of those example are supposed to work. We can't define property semantics to be "just like data" when property symbol can't be just interchanged with data symbol. From the syntax point of view no issues there.

From my stance that  property should make the function behave like a

	struct Type
	{
	     property void native(int);
	}

This should behave as though you wrote this: struct Type { // const because there is no setter const int native; }
	 property void external1(int);       // valid? (no assignment context)

Valid, this is equivalent to defining a module-level variable: int external1;
	 property void external2(Type, int); // valid? (extra parameter comparing to
typical setter)

Valid, because UFCS lets you use it as though it were a member variable of Type.
	void main()
	{
	    Type t;
	    t.native = 42;    // typical
	    external1 = 42;   // allowed or not?

Allowed, because external1 behaves like a module-level variable.
	    42.external1;     // allowed or not?

Not allowed, because the following isn't allowed either: int x; void main() { 1.x; // Error: nonsensical syntax } IOW, property functions must be treated as variables externally, NOT as normal functions.
	    t.external2 = 42; // allowed or not?
	}

Allowed, because external2, via UFCS, behaves as though it were a member variable of Type. All of the confusing/unclear/ambiguous cases come from an incomplete implementation of property and an unnecessary conflation with normal functions. A property function should not be treated like a normal function. It turns the function into a variable-like entity that *no longer acts like a function to the outsider*. Neither should normal functions for whatever strange reasoning be conflated with property functions, because functions are not variables. It's actually very straightforward once you remove all the unnecessary conflations, and disregard, for the time being, the problems in the current implementation. T -- There is no gravity. The earth sucks.
Jan 25 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Jan 2013 14:59:58 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 I agree with all of the above. There has been a fair amount of 
 rationalization and appeal to emotion on all sides. It would be great
 to get back to reason and clearly compartmentalize objective
 arguments (of which there have been a few very profound ones) and
 personal preference.

Do that on this wiki page: http://wiki.dlang.org/Property_Discussion_Wrap-up
 There's more " property" to be seen with "save" and "back".
 Subjectively that just didn't work well for me. It adds clutter to an
 otherwise simple and straightforward API, and penalizes usage for
 benefits that I could never reap.

I think it actually makes sense. I even tried writing ranges for std.digest where front was not a property but a field and was surprised it didn't work. (isInputRange shouldn't check for property. It should check for "can be used like a field" which means field+property.).
 I understand how some people are
 glad to put that in everywhere, and find meaning in requiring parens
 with popFront and popBack but not the others. Yet for me it was
 liberating (see 1 above too) I could just write "r.popFront" without
 the parens and have it do its deed. It is the right semantics for a
 simple syntax.

Please read the wiki page. popFront or popFront() is orthogonal to the property discussion.
 
 3. Whatever we do going forward should be _simple_ but not
 _simplistic_. Right now it's easy to forget that we're all close to
 the subject. We have it in working memory (at least it's what I think
 about all the time) and any incremental complexity is an easy cost to
 absorb intellectually.
 
 But when we need to teach this to newcomers or even approach it again 
 with a "cold cache", any undue complexity will be jarring.

Wiki page, wiki page ;-)
 
 4. Whether we like it or not, backward compatibility is an issue. The 
 parens or no parens aspect upon a function call is too ubiquitous to 
 write off as an obscure circumstance. So I don't think the obscurity 
 argument applies.
 
 Granted, there are several ways to approach the compatibility issue,
 all with their specific tradeoffs. All I'm saying is that careful 
 considerations of compatibility must be integral to whatever we do
 about this.

The approach described on the wiki does break some code, but that code shouldn't compile anyway: property functions with wrong number of arguments and similar stuff. Only controversial thing is taking the address of a property, but I can't think of a solution which would work well with generic code so I'd just say forbid that.
 
 5. This is a matter in which reasonable people may disagree. For
 better or worse Walter and to a lesser extent myself are in the
 position to decide. We're doing the best to gather, mind, and
 integrate opinions and suggestions but clearly no decision that would
 please everyone.

Would be nice if the arguments for the final decision are added to the wiki page :-)
Jan 25 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 25 January 2013 at 20:10:01 UTC, Nick Sabalausky wrote:
 What really got me upset about it was that here we have one of 
 my favorite modern language features, properties, and then all 
 of a sudden *both* the top #1 and #2 people behind D start 
 trying to
 gut it if not outright remove it from the language entirely

Amen.
Jan 25 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Friday, 25 January 2013 at 20:10:01 UTC, Nick Sabalausky wrote:
 What really got me upset about it was that here we have one of 
 my
 favorite modern language features, properties, and then all of 
 a sudden
 *both* the top #1 and #2 people behind D start trying to gut it 
 if not
 outright remove it from the language entirely, instead of 
 enacting, or
 at least promising to *eventually* enact, the long overdue 
 fixes I've
 been anxiously awaiting.

If I correctly understand Walters proposal and Andrei's view point, neither are proposing to fully axe property-like behavior. I stand to be corrected, but they both seem to think that enforcement through property is not required, and that's the main point being put on the chopping block. Walter and Andrei may want to clarify since I cannot speak for them. --rt
Jan 25 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 25, 2013 at 09:06:44PM +0100, Johannes Pfau wrote:
 Am Fri, 25 Jan 2013 10:39:50 -0800
 schrieb "H. S. Teoh" <hsteoh quickfur.ath.cx>:
 
 
 - It's illegal to mark a function that takes 2 or more arguments as
    property, because it makes no sense.
 

3 or more arguments. UFCS properties have 2 arguments: property void age(Person p, int value); //OK, bad example, but you get the idea

Good point, so it's 2 or more arguments for member functions, and 3 or more for module-level functions. Another thing I forgot to mention: once a function has been declared property, you cannot call it like a normal function anymore. So if you declare at the module level: property void age(Person p, int value); then: void main() { Person p; //age(p, 123); // Error: cannot call age like a normal function //p.age(123); // ditto p.age = 123; // OK } The second case (p.age(123)) is valid only if age() returns a delegate. Again, property turns the function into a variable-like entity that does not behave like a normal function to the outside world. T -- Lottery: tax on the stupid. -- Slashdotter
Jan 25 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 25 January 2013 at 19:59:59 UTC, Andrei Alexandrescu 
wrote:
 2. I have tried to add  property appropriately in Phobos, in 
 particular for ranges:

These are examples of why I'm firmly in the pro-optional parenthesis camp. With them, stuff like this becomes irrelevant; it works either way. But, remember, the problem property needs to solve is none of this. There's no pressing reason to put it on range functions. My view is property maybe somewhat rare in usage: if in doubt, do NOT use it. But there's cases where there is no doubt, and we don't want to throw the baby out with the bathwater there. One example where I'd love property: a dynamic object. Suppose we extend Variant to work Javascript style: Variant v; v.prop = function() { }; v.prop(); // we expect this to call the function, not return a reference to it That would be an property.... range.popFront doesn't need to be. It works fine with the existing optional parenthesis rule.
Jan 25 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Jan 2013 12:12:55 -0800
schrieb "H. S. Teoh" <hsteoh quickfur.ath.cx>:

 
 
	struct Type
	{
	     property void native(int);
	}

This should behave as though you wrote this: struct Type { // const because there is no setter const int native; }

Only if the getter is marked as const. We can discuss if that should be required, but in the code above, native isn't necessarily const.
 
 All of the confusing/unclear/ambiguous cases come from an incomplete
 implementation of  property and an unnecessary conflation with normal
 functions. A  property function should not be treated like a normal
 function. It turns the function into a variable-like entity that *no
 longer acts like a function to the outsider*. Neither should normal
 functions for whatever strange reasoning be conflated with  property
 functions, because functions are not variables.
 

another proposal to it: http://wiki.dlang.org/Property_Discussion_Wrap-up
Jan 25 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Jan 2013 21:28:34 +0100
schrieb Johannes Pfau <nospam example.com>:

 Am Fri, 25 Jan 2013 12:12:55 -0800
 schrieb "H. S. Teoh" <hsteoh quickfur.ath.cx>:
 
 
 
	struct Type
	{
	     property void native(int);
	}

This should behave as though you wrote this: struct Type { // const because there is no setter const int native; }

Only if the getter is marked as const. We can discuss if that should be required, but in the code above, native isn't necessarily const.

Ah you fooled me! There is only a setter in the first example!
Jan 25 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 10:39:50 H. S. Teoh wrote:
 I've refrained so far from participating in this thread, but maybe it's
 time to say something.

Another issue that you didn't mention (and which hasn't come up in this particular discussion, I don't believe) is what to do about disambiguating property functions that conflict. You can't use the full import path for a function when using the property syntax, so there's not currently a way to disambiguate property functions which conflict. So, we'll need to find a solution for that. - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent reply "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
Here are my two cents:

First, about optional parentheses:

Optional parentheses = ambiguity.

int foo() { return 4; }
auto x = foo; // gives 4 or gives function foo?

It seems to me any ambiguity should be an error. However… it only 
matters when the type system can't provide the missing detail, as 
above.

The ambiguity may be resolved either in the function signature or 
at the call site.  property partly helps resolve it at the 
function signature, but it is a different issue from optional 
parentheses.

Ambiguity can also be resolved at the call site instead of the 
function signature. It needs to be as clear and concise as 
possible in addition to being unambiguous. D's method of 
disambiguating cases often uses the keyword "cast". Applying it 
in this case would lead to "cast(function)" or "cast(delegate)" 
to indicate the function and not the return value, where the 
default is to indicate the return value.

int foo() { return 4; }
int function() goo() { return foo; }

auto doh = foo(); // gives 4
auto go = foo; // Error: can't deduce type of expression foo
auto fun = cast(function) foo; // gives foo

auto ae = goo; // Error: can't deduce type (either goo or 
function int() foo )
auto fe = goo(); // Error: can't deduce type (either foo or 4)
auto ga = goo()(); // gives 4
auto gu = cast(function) (goo()); // gives foo
auto gi = cast(function) goo; // gives goo

This solution is unambiguous and clear, but unfortunately not 
very concise. In fact, "cast(function) foo" is rather a long way 
of saying "&foo", but much clearer and possibly safer. The type 
system can probably resolve most of these ambiguities anyway, 
which would mean the cast wouldn't appear very often, but I'm not 
sure.

I have no real opinion about  property. Ideally the compiler 
could deduce what is and isn't a property without the ugly 
 property attached to all the signatures, but it might invite so 
many abuses of this process that it's not worth it.
Jan 25 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 10:44 PM, Zach the Mystic wrote:
 Here are my two cents:

 First, about optional parentheses:

 Optional parentheses = ambiguity.
 ...

No, you can definitely have ambiguity without optional parentheses. Unless that is supposed to be a destructive update. Is your statement ambiguous?
 int foo() { return 4; }
 auto x = foo; // gives 4 or gives function foo?

 It seems to me any ambiguity should be an error. However… it only
 matters when the type system can't provide the missing detail, as above.
 ...

That is not ambiguous.
Jan 25 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Friday, 25 January 2013 at 21:20:33 UTC, Andrei Alexandrescu 
wrote:
 On 1/25/13 3:18 PM, Rob T wrote:
 On Friday, 25 January 2013 at 20:10:01 UTC, Nick Sabalausky 
 wrote:
 What really got me upset about it was that here we have one 
 of my
 favorite modern language features, properties, and then all 
 of a sudden
 *both* the top #1 and #2 people behind D start trying to gut 
 it if not
 outright remove it from the language entirely, instead of 
 enacting, or
 at least promising to *eventually* enact, the long overdue 
 fixes I've
 been anxiously awaiting.

If I correctly understand Walters proposal and Andrei's view point, neither are proposing to fully axe property-like behavior. I stand to be corrected, but they both seem to think that enforcement through property is not required, and that's the main point being put on the chopping block. Walter and Andrei may want to clarify since I cannot speak for them.

That's right with the amendment that we're looking for a solution, not pushing one. Even the title of the thread is a question. Clearly properties are good to have. In an ideal world we wouldn't need a keyword for them and we'd have some simple rules for determining property status (especially when it comes to writes). If syntactic help is necessary, so be it. We want to make the language better, not worse. Andrei

OK, understood. I started a discussion in wiki showing how property-like behaviour without full variable emulation can work unambiguously for a few of the edge cases, such as reference returns and taking the addresses, eg, &prop. http://wiki.dlang.org/Talk:Property_Discussion_Wrap-up#ref_returns_and_taking_the_address If we try and fully emulate variables, a ton of complexity starts to creep in. If we do not fully emulate variables, then it significantly weakens the arguments in favor of using property as a means to emulate variable. --rt
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
2 cents regarding your position on " property" usage in phobos:

1) You can always use shorter syntax:
 property:
int func1();
int func2();
...

2) D is not scripting language (primarily) and as such should 
value issues related to long-term large code base support more 
than saving some typing in declaration. It is slightly similar to 
strong vs weak typing.

That is not gonna convince you but I hope this will be taken into 
consideration somehow.
Jan 25 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Friday, 25 January 2013 at 21:51:14 UTC, mist wrote:
 2 cents regarding your position on " property" usage in phobos:

 1) You can always use shorter syntax:
  property:
 int func1();
 int func2();
 ...

This already works property { int func1(); int func2(); } --rt
Jan 25 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 14:59:58 Andrei Alexandrescu wrote:
 2. I have tried to add  property appropriately in Phobos, in particular
 for ranges:
 
 struct SomeRange {
  property bool empty();
  property ref T front();
 void popFront();
 }
 
 There's more " property" to be seen with "save" and "back". Subjectively
 that just didn't work well for me. It adds clutter to an otherwise
 simple and straightforward API, and penalizes usage for benefits that I
 could never reap. I understand how some people are glad to put that in
 everywhere, and find meaning in requiring parens with popFront and
 popBack but not the others. Yet for me it was liberating (see 1 above
 too) I could just write "r.popFront" without the parens and have it do
 its deed. It is the right semantics for a simple syntax.

That's simply a question of being able to make function calls without parens. That's different from the question of properties, much as there may be syntactic similarities. While properties do involve not using parens, there's a lot more to them than simply not using parens. A property function is fundamentally different from a normal function by its very nature, not just by its call syntax. A property is an abstraction for a variable (and therefore should be swappable with a variable), whereas a function is explicitly an action. So, regardless of what we do with parenless function calls, getting rid of explicit properties will have serious side effects.
 5. This is a matter in which reasonable people may disagree. For better
 or worse Walter and to a lesser extent myself are in the position to
 decide. We're doing the best to gather, mind, and integrate opinions and
 suggestions but clearly no decision that would please everyone. So
 please bear with us. I understand this may be frustrating but the best
 we all can do is think beyond our own preference and on behalf of the
 larger community.

If we throw away property, then it will be impossible to swap between using variables and property functions, which is one of the main purposes of properties. For instance, it should be possible for a range's front to be variable if that range doesn't need a function for it. There are currently implementation problems with property which prevent us from being able to do that with property, but they can be fixed. However, without explicit properties of some kind, it's just not possible. Not only are the semantics of a property function still too different from a variable (e.g. += doesn't yet work with a property function), but the issue of parens on property functions is a problem. We need to able to make it so that it's illegal to use parens on a property function, not only so that you could potentially swap it out for a public variable if the function was no longer needed but more importantly so that generic APIs (such as ranges) can guarantee that using a variable instead of a property function will work (e.g. if you can call front with parens, then front can never be an actual variable). And for that, you need explicit properties, not just the syntactic sugar of being allowed to drop parens. Also, too much of this discussion has focused on getters. property also has a large impact with setter properties. Without it, you'll be able to do stuff like range.popFrontN = 7; "hello".icmp = "world"; "/usr/bin".buildPath = "dmd"; which makes no sense. As long as we have explicit properties, we can restrict the setter syntax to functions that are actually properties and could conceivably be replaced with variables. Without them, arbitrary functions could be set as if they were variables, many (most?) of which would make absolutely no sense as variables under any circumstances. Keeping parenless functions is one thing, but getting rid of explicit properties is another thing altogether. - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 23:04:58 Rob T wrote:
 On Friday, 25 January 2013 at 21:51:14 UTC, mist wrote:
 2 cents regarding your position on " property" usage in phobos:
 
 1) You can always use shorter syntax:
  property:
 int func1();
 int func2();
 ...

This already works property { int func1(); int func2(); }

They both already work and have do so for ages. - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 22:15:51 UTC, Jonathan M Davis 
wrote:
 They both already work and have do so for ages.

 - Jonathan M Davis

Erm? Yes, and thus it was an answer to "you need to mess every function declaration with an annotation"
Jan 25 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 23:23:50 mist wrote:
 On Friday, 25 January 2013 at 22:15:51 UTC, Jonathan M Davis
 
 wrote:
 They both already work and have do so for ages.
 
 - Jonathan M Davis

Erm? Yes, and thus it was an answer to "you need to mess every function declaration with an annotation"

I know. I was responding to Rob's post which implied that the syntax you gave didn't currently work. - Jonathan M Davis
Jan 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-26 02:48, Jonathan M Davis wrote:

 : works works with any function attribute, as does {}.

And even for user defined attributes :) -- /Jacob Carlborg
Jan 26 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Friday, 25 January 2013 at 22:39:07 UTC, Jonathan M Davis 
wrote:
 On Friday, January 25, 2013 23:23:50 mist wrote:
 On Friday, 25 January 2013 at 22:15:51 UTC, Jonathan M Davis
 
 wrote:
 They both already work and have do so for ages.
 
 - Jonathan M Davis

Erm? Yes, and thus it was an answer to "you need to mess every function declaration with an annotation"

I know. I was responding to Rob's post which implied that the syntax you gave didn't currently work. - Jonathan M Davis

I misread the post by mist, I incorrectly thought that it was a new syntax proposal as I did not know about property:. --rt
Jan 25 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Friday, 25 January 2013 at 22:02:06 UTC, Timon Gehr wrote:
 On 01/25/2013 10:44 PM, Zach the Mystic wrote:
 Here are my two cents:

 First, about optional parentheses:

 Optional parentheses = ambiguity.
 ...

No, you can definitely have ambiguity without optional parentheses. Unless that is supposed to be a destructive update. Is your statement ambiguous?

Actually, you're right. I meant: Optional parentheses as a feature leads to ambiguity precisely when they are not used.
 int foo() { return 4; }
 auto x = foo; // gives 4 or gives function foo?

 It seems to me any ambiguity should be an error. However… it 
 only
 matters when the type system can't provide the missing detail, 
 as above.
 ...

That is not ambiguous.

But this time *your* comment is ambiguous! If you mean my *statement* is not ambiguous, then yes.
Jan 25 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Saturday, 26 January 2013 at 00:47:38 UTC, Zach the Mystic 
wrote:
 That is not ambiguous.

But this time *your* comment is ambiguous! If you mean my *statement* is not ambiguous, then yes.

Actually, that's ambiguous too. My English language statement.
Jan 25 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 23:56:24 Rob T wrote:
 I misread the post by mist, I incorrectly thought that it was a
 new syntax proposal as I did not know about  property:

: works works with any function attribute, as does {}. - Jonathan M Davis
Jan 25 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+d gmail.com> writes:
On Friday, 25 January 2013 at 21:44:28 UTC, Zach the Mystic wrote:
 Here are my two cents:

 First, about optional parentheses:

 Optional parentheses = ambiguity.

 int foo() { return 4; }
 auto x = foo; // gives 4 or gives function foo?\

4, we are talking about D not C.
Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 19:59:59 UTC, Andrei Alexandrescu 
wrote:
 1. Syntactic and semantic implications of properties that 
 return callable entities

I don't understand why this is a special case in the first place. It should behave just like a variable of the same type, period.
 C has no methods so the syntax "object.method" does not apply 
 to it. In C++, "object.method" is probably the oddest construct 
 in the entire language: it returns a type that exists but has 
 no name, is not expressible syntactically, is not first class 
 (one can't assign "object.method" to a variable), and has only 
 two allowed operations: take address or apply the function call 
 operator "()". Various C++ implementations have extensions that 
 fix this.

 Both Walter and I consider these serious lapses in language 
 design. Two of the most accessible elements of syntax do things 
 of considerably low interest and use. I hope I now clarified 
 why I have a dim view of arguments that - implicitly or 
 explicitly - assume the C or C++ behavior in this area is an 
 example to follow on technical grounds. (Clearly, familiarity 
 is a much better argument.)

Javascript or C# have solved that issue with C like language nicely. That is why I propose to do the same here (and considering how much C# has been mentioned here, it sound like a serious option). I know that Javascript is a poorly designed language, but on that very specific topic most people agree that was has been done at the time was pure genius. It removes the weird C/C++ object that have no expressible type, and simplify the situation. Additional benefice is that funName now behave the same in all situation, which is also a simplification of the situation.
 2. I have tried to add  property appropriately in Phobos, in 
 particular for ranges:

 struct SomeRange {
    property bool empty();
    property ref T front();
   void popFront();
 }

 There's more " property" to be seen with "save" and "back". 
 Subjectively that just didn't work well for me. It adds clutter 
 to an otherwise simple and straightforward API, and penalizes 
 usage for benefits that I could never reap. I understand how 
 some people are glad to put that in everywhere, and find 
 meaning in requiring parens with popFront and popBack but not 
 the others. Yet for me it was liberating (see 1 above too) I 
 could just write "r.popFront" without the parens and have it do 
 its deed. It is the right semantics for a simple syntax.

If you ask me, I think property have been abused in range design. Many ranges properties really shouldn't be properties. Additionally, this kind of boilerplate can easily be written by automated tools. Java or C# are very verbose, but it is very efficient to write program in them, as the tooling to a great job for you. As I discussed with you, tooling appears slowly in D because the language itself is unstable, the specification have many quirks, and dmd is not reusable for the job. We can either make more quirks in order to make our life easier, or less quirks in order for tools to make our life easier. The first one have immediate return on investment, however, it is shortsighted IMO.
 3. Whatever we do going forward should be _simple_ but not 
 _simplistic_. Right now it's easy to forget that we're all 
 close to the subject. We have it in working memory (at least 
 it's what I think about all the time) and any incremental 
 complexity is an easy cost to absorb intellectually.

 But when we need to teach this to newcomers or even approach it 
 again with a "cold cache", any undue complexity will be jarring.

Everybody know how a variable behave. This is the most simple and straightforward way for a property to work.
 4. Whether we like it or not, backward compatibility is an 
 issue. The parens or no parens aspect upon a function call is 
 too ubiquitous to write off as an obscure circumstance. So I 
 don't think the obscurity argument applies.

 Granted, there are several ways to approach the compatibility 
 issue, all with their specific tradeoffs. All I'm saying is 
 that careful considerations of compatibility must be integral 
 to whatever we do about this.

Whatever solution we choose, it will break stuff. We'd better think of a nice way to handle the transition than a way to not break code. Think that PHP went from value typed object to reference typed object between 4 and 5. This is a major breakage of a codebase that is much bigger than D's. I was made possible by a great release management. We'd better acknowledge that our release management sucks, and fix that, than fearing the consequences of it everywhere.
Jan 25 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Saturday, 26 January 2013 at 05:39:05 UTC, Walter Bright wrote:
 On 1/25/2013 2:14 PM, Jonathan M Davis wrote:
 A property function is fundamentally different from a
 normal function by its very nature, not just by its call 
 syntax.

I would have agreed with you on that for years, simply taking its veracity as an axiom, but lately I am not convinced at all of that assertion. I suspect the differences between a property, field, and method are purely contrivance. For example, even accessing a global variable isn't straightforward, if you look under the hood. If it's in a DLL or TLS, there may be a function call in there that is non-trivial.

Walter, that's not how TLS variables are generally implemented in C/C++. They're *normal* variables, placed in a special section of the executable, which is automatically switched in and out on every context switch by the OS. This is true on Windows, and I believe in Linux as well (http://stackoverflow.com/questions/2459692)
Jan 25 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Saturday, 26 January 2013 at 07:25:24 UTC, Walter Bright wrote:
 On 1/25/2013 10:06 PM, Mehrdad wrote:
 Walter, that's not how TLS variables are generally implemented 
 in C/C++.

Since I implemented them, I know how they work.

I wasn't being pedantic. That's why I said generally, not always. Obviously you can implement things a million different ways...
 They're *normal* variables, placed in a special section of the 
 executable, which
 is automatically switched in and out on every context switch 
 by the OS.

This is not necessarily true at all. It isn't for OSX, for example, and there's nothing in the semantics of TLS which preclude calling a function.

Again, I didn't say they're "necessarily" true either, hence why I mentioned Linux and Windows specifically. OS X is really the odd one out here, not Windows or Linux. But you missed my point, which was, yes, a lot of things COULD contain function calls. Even the two lines int i = 0; i++; COULD contain a function call, but how is that in any shape or form relevant to the discussion about property in any way? Generally, it isn't a function call, and as far as the code is concerned, it isn't a function call. The fact that you may have happened to implement something as a function call doesn't mean anything with regards to the difference between a function call and a direct access for the _programmer_.
Jan 25 2013
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
 please give us your own code and preferred solution
 to compile-time formatting string checking.

general problem to incorporate expectable many DSL's into one big source base, as D is intended to serve large scale coding.

And what's the solution, for you? Using strings as DSL is somewhat common in D. As for DSL, well, I have a parser generator project here (https://github.com/PhilippeSigaud/Pegged), and I recently added the capacity to add new rules to a grammar at runtime and modify the resulting parse tree. I also used the existent, but unused macro keyword in D to get source code that can define its own subsequent grammar and parse tree transformations. Oh, and grammars can call one another, so adding a new sublanguage to a parent language is doable (I use this from time to time). I still have weeks fo work on this to have it reach the level I want, but I did not hit any wall up to now. So adding clean-looking DSL can be done in D, I think.
 I am sure that your "stab at it" does not show any intent to
 approach the general problem.

No, indeed :) Since it's a recurring question here, I just showed it could be done. It's also a simple example of what can be done with D meta-programming capacities.
Jan 25 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 26 January 2013 at 08:29:40 UTC, Dmitry Olshansky 
wrote:
 Automated tooling is admitting a defeat if we talk about 
 expressive languages. Java was designed with automatic code 
 manipulation in mind and even with todays proliferation of 
 generators it's a pain to work with.

 TL;DR code is written once and read many times.

Using tooling is admitting defeat ? That is very misplaced pride (and not even an argument). And if you think that verbose code is less readable, think twice, or follow both links : http://code.jquery.com/jquery.js http://code.jquery.com/jquery.min.js No doubt the less verbose one is more readable !
Jan 26 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 26 January 2013 at 09:04:47 UTC, Walter Bright wrote:
 On 1/25/2013 11:52 PM, Mehrdad wrote:
 The fact that you may have happened to implement something as 
 a function call
 doesn't mean anything with regards to the difference between a 
 function call and
 a direct access for the _programmer_.

I.e. the difference is purely a contrivance, which was my point.

Yes, that the whole point of abstraction. It happen that variables and functions are both very useful ones.
Jan 26 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Jan 2013 21:38:44 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:

 On 1/25/2013 2:14 PM, Jonathan M Davis wrote:
 A property function is fundamentally different from a
 normal function by its very nature, not just by its call syntax.

I would have agreed with you on that for years, simply taking its veracity as an axiom, but lately I am not convinced at all of that assertion. I suspect the differences between a property, field, and method are purely contrivance. For example, even accessing a global variable isn't straightforward, if you look under the hood. If it's in a DLL or TLS, there may be a function call in there that is non-trivial.

Although variable access might be implemented as a non-trivial function calls everyone tries to make these as fast as possible. Think of PLT/GOT or the TLS register on ARM processors. And this is the difference between variable/property and function: Access to the former has to be 'fast'. There's no real definition of fast in this case, but I doubt an O(n^2) implementation of TLS or variable access in general would be acceptable to anyone.
Jan 26 2013
prev sibling next sibling parent luka8088 <luka8088 owave.net> writes:
On 24.1.2013 9: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.

 3. Parens are required for calling delegates or function pointers.

 4. No more  property.

Maybe one possible issue to note. I am sorry if someone already noted this but I didn't saw it so here it is. In druntime's object_.d AssociativeArray has: property size_t length() { return _aaLen(p); } By removing property typeof([].length) is no longer uint or ulong. It would change into uint() or ulong(). And not just for length, but any other properties type's would change. I think that this is one big possible code breaker for everyone that uses something similar to the following: typeof([].length) l = [].length; Maybe I am wrong but my personal opinion is that code like this should compile because semantically length is a property and the fact that it is a functions is just a implementation detail.
Jan 26 2013
prev sibling next sibling parent "Nicolas Sicard" <dransic gmail.com> writes:
On Saturday, 26 January 2013 at 13:21:37 UTC, Jacob Carlborg 
wrote:
 It's always possible to avoid keywords in favor of syntax. 
 Example:

 Declaring a getter:

 int foo {}

 Just as a regular function declaration but without the 
 parentheses.

 Declaring a setter:

 void foo= (int value) {}

 Append an equal sign to the function name.

How would you declare a template property? The getter would be ambiguous with a regular function declaration, wouldn't it?
Jan 26 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 26 January 2013 at 13:28:46 UTC, Jacob Carlborg 
wrote:
 On 2013-01-25 19:00, Rob T wrote:

 Why was a partial implementation of an experimental 
 half-backed idea
 released into the wild?

It seems just to be how things are done in the D community. Another recent example of this is the UDA that popped up and got implemented from nowhere.

That is probably the #1 problem with D.
Jan 26 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 26 January 2013 at 13:28:46 UTC, Jacob Carlborg 
wrote:
 Another recent example of this is the UDA that popped up and 
 got implemented from nowhere.

That design is almost identical to a discussion we had a few months ago about it though; the timing was a surprise, but it wasn't bungled the way property was.
Jan 26 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 26 January 2013 at 16:29:16 UTC, Andrei Alexandrescu 
wrote:
 On 1/26/13 8:21 AM, Jacob Carlborg wrote:
 On 2013-01-25 22:20, Andrei Alexandrescu wrote:

 That's right with the amendment that we're looking for a 
 solution, not
 pushing one. Even the title of the thread is a question.

 Clearly properties are good to have. In an ideal world we 
 wouldn't need
 a keyword for them and we'd have some simple rules for 
 determining
 property status (especially when it comes to writes). If 
 syntactic help
 is necessary, so be it. We want to make the language better, 
 not worse.

It's always possible to avoid keywords in favor of syntax. Example: Declaring a getter: int foo {} Just as a regular function declaration but without the parentheses. Declaring a setter: void foo= (int value) {} Append an equal sign to the function name.

This is interesting. I wonder how to make it work for UFCS functions (which _do_ have one argument).

I have to say it will get my vote if a way if found to make this UFCS compliant.
Jan 26 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 26 January 2013 at 13:21:37 UTC, Jacob Carlborg 
wrote:
 It's always possible to avoid keywords in favor of syntax. 
 Example:

 Declaring a getter:

 int foo {}

 Just as a regular function declaration but without the 
 parentheses.

 Declaring a setter:

 void foo= (int value) {}

 Append an equal sign to the function name.

This looks nice, but I favor for C# properties. The root of the issue is that in C/C++/D there is tremendous difference between object types and functions types (which are incompatible) and property is like a bridge between them - I think that is why the feature is demanded. However in D a property is essentially a function. Few characteristics that are intrinsic to data types are typeof(prop) which is data type for properties and parenthesis-less access. There is no property as a special entity per se. In C# property and getter/setter are separated, so there is no confusion between data and functions. In D it would look like this: class A { private int i; property int foo // may be without property at all? { get { return i; } set { i = value; } } } In this solution property is not defined by naming of two separate functions and is independent of any function in general.
Jan 26 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sat, 26 Jan 2013 11:10:20 -0800, Maxim Fomin <maxim maxim-fomin.ru>  
wrote:

 On Saturday, 26 January 2013 at 13:21:37 UTC, Jacob Carlborg wrote:
 It's always possible to avoid keywords in favor of syntax. Example:

 Declaring a getter:

 int foo {}

 Just as a regular function declaration but without the parentheses.

 Declaring a setter:

 void foo= (int value) {}

 Append an equal sign to the function name.

This looks nice, but I favor for C# properties. The root of the issue is that in C/C++/D there is tremendous difference between object types and functions types (which are incompatible) and property is like a bridge between them - I think that is why the feature is demanded. However in D a property is essentially a function. Few characteristics that are intrinsic to data types are typeof(prop) which is data type for properties and parenthesis-less access. There is no property as a special entity per se. In C# property and getter/setter are separated, so there is no confusion between data and functions. In D it would look like this: class A { private int i; property int foo // may be without property at all? { get { return i; } set { i = value; } } } In this solution property is not defined by naming of two separate functions and is independent of any function in general.

C# does not have a property keyword precisely because get/set are enough for the compiler to determine whether or not it is a property. So this is completely valid C#: class A { private int i; public int foo { get { return i; } set { i = value; } } } -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 26 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Saturday, 26 January 2013 at 21:48:54 UTC, Artur Skawina wrote:
[..]
 Hmm, the current state of them being defined by two separate 
 functions really
 isn't ideal. But introducing new keywords or magic identifiers 
 just for this
 does not seem right.

    class A
    {
        private int i;
        int foo {
            out { return i; }
            in(int v) { i = v; }
        }
    }

 or

    class A
    {
        private int i;
         property foo {
            int out { return i; }
            in(int v) { i = v; }
        }
    }

 artur

In a more pefect world, we'd redefine what a variable and function is, merging the two together as one, let the compiler optimize things appropriately, and make the language issues far more consistent and simple. For example, typeof(x) is way too simplistic to be of use when you have objects that have more than on type. For example, a property has a setter, getter, and storage type, so what should typeof(prop) return? It can only tell you one thing out of at least 3 things, so it's insufficient. Great for C, useless for D. We're basically finding ourselves in the same position C++ has found itself in, where the old concepts are no longer suitable for a modern language, but there's no practical way to resolve the situation without redesigning the whole language into a new one. D tried to make a better C++, and it has done a good job of that up to a point, but since it has made use of many of the old paradigms as its base, it can only do so much. One solution is to not bother trying to add on any extra complexity that does not fit in. --rt
Jan 26 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
We can almost implement properties as a regular struct

struct prop
{
     int _val;
     ref prop opAssign( int a_val )
     {
         writeln("assignment = ", a_val );
         _val = a_val;
         return this;
     }
     int opCall()
     {
         writeln("opcall = ", _val );
         return _val;
     }

     // other op overloads, like ++, --, etc

}

If we change a few things it may work. Instead of struct it could 
be named prop

eg

prop P
{

    ...

}

opCall needs to be changed so there's no need to specify the (). 
No dounbt other changes will be needed too to make it more 
convenient to use and less error prone.

The advantage is that with a "property as a struct" 
implementation, you can wrap up a lot more than just a setter and 
getter around only one variable, eg internally there could be 
several vars or even none at all depending on the needs.

--rt
Jan 26 2013
prev sibling next sibling parent Ziad Hatahet <hatahet gmail.com> writes:
--047d7b3a7fea9d168404d43a5f76
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jan 26, 2013 at 2:24 PM, Rob T <alanb ucora.com> wrote:

 We're basically finding ourselves in the same position C++ has found
 itself in, where the old concepts are no longer suitable for a modern
 language, but there's no practical way to resolve the situation without
 redesigning the whole language into a new one. D tried to make a better
 C++, and it has done a good job of that up to a point, but since it has
 made use of many of the old paradigms as its base, it can only do so much.

lurker, I like many of the concepts that D introduces, but the many little quirks here and there add up and probably make adoption by a large community much less likely. It would be great if we had more programming languages competing to change the systems programming landscape. The popular systems languages we have been stuck with (namely C and C++) are a mess, and the "replacements" I see announced every once in a while never seem to become bigger than side projects. Currently, the only other potential option I see is Rust. Why not take it all the way? Start with a proper release plan, be willing to break backward compatibility (maybe even by changing the name of the language -- perception matters), take into account all what was learned from the past 10+ years of D's history, potentially try to get corporate backing, and maybe we will have something that is practically viable to push aside C and C++. Then again, maybe I dream too much... -- Ziad --047d7b3a7fea9d168404d43a5f76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jan 26, 2013 at 2:24 PM, Rob T <span dir=3D"ltr">&lt;<a href=3D"mai= lto:alanb ucora.com" target=3D"_blank">alanb ucora.com</a>&gt;</span> wrote= :<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> We&#39;re basically finding ourselves in the same position C++ has found it= self in, where the old concepts are no longer suitable for a modern languag= e, but there&#39;s no practical way to resolve the situation without redesi= gning the whole language into a new one. D tried to make a better C++, and = it has done a good job of that up to a point, but since it has made use of = many of the old paradigms as its base, it can only do so much.<br> <br></blockquote><div><br>That is what I have been noticing as well, unfort= unately.=A0 As a long time lurker, I like many of the concepts that D intro= duces, but the many little quirks here and there add up and probably make a= doption by a large community much less likely.<br> <br>It would be great if we had more programming languages competing to cha= nge the systems programming landscape. The popular systems languages we hav= e been stuck with (namely C and C++) are a mess, and the &quot;replacements= &quot; I see announced every once in a while never seem to become bigger th= an side projects. Currently, the only other potential option I see is Rust.= <br> <br>Why not take it all the way? Start with a proper release plan, be willi= ng to break backward compatibility (maybe even by changing the name of the = language -- perception matters), take into account all what was learned fro= m the past 10+ years of D&#39;s history, potentially try to get corporate b= acking, and maybe we will have something that is practically viable to push= aside C and C++.<br> </div><div><br>Then again, maybe I dream too much...<br><br clear=3D"all"><= div>--<br>Ziad</div>=A0 <br></div></div><br> --047d7b3a7fea9d168404d43a5f76--
Jan 26 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 25 January 2013 at 18:03:54 UTC, Rob T wrote:
 On Friday, 25 January 2013 at 17:52:12 UTC, Dmitry Olshansky 
 wrote:
 Instead, we should be trying to continuously expand the 
 things we
 guarantee will continue to work. Ideally we would be precise 
 about the
 things that are likely to change, and which we don't 
 currently guarantee.

+1

I agree with this completely, but we cannot do it until there's a full implementation of a reasonably designed and followed development and release process that includes the language specification. --rt

+1 The language has reached a point where bugs in the spec are more important than bugs of the implementation. In fact many difficult bugs in the implementation are rooted in spec issues.
Jan 27 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 09:51:04 UTC, SomeDude wrote:
 On Friday, 25 January 2013 at 18:03:54 UTC, Rob T wrote:
 On Friday, 25 January 2013 at 17:52:12 UTC, Dmitry Olshansky 
 wrote:
 Instead, we should be trying to continuously expand the 
 things we
 guarantee will continue to work. Ideally we would be precise 
 about the
 things that are likely to change, and which we don't 
 currently guarantee.

+1

I agree with this completely, but we cannot do it until there's a full implementation of a reasonably designed and followed development and release process that includes the language specification. --rt

+1 The language has reached a point where bugs in the spec are more important than bugs of the implementation. In fact many difficult bugs in the implementation are rooted in spec issues.

I went to stress the "followed" part. I.e. we do have quite a good release process description on wiki with some related parts also mentioned. But if it is followed as good as upon 2.061, it makes not difference.
Jan 27 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis 
wrote:
 I hate optional parentheses with a passion

 - Jonathan M Davis

Same here.
Jan 27 2013
prev sibling next sibling parent "sclytrack" <sclytrack shorter.com> writes:
On Sunday, 27 January 2013 at 10:54:05 UTC, SomeDude wrote:
 On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis 
 wrote:
 I hate optional parentheses with a passion

 - Jonathan M Davis

Same here.

In Delphi they are also optional and nobody uses them. However, everybody else doesn't use them. :-)
Jan 27 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
int CoolThing { in; out; } - auto property without implementation;

int CoolThing { private in; out; } - private setter; public 
getter;

int CoolThing
{
    in
    {
       _privateCoolThing =  value * 42;
    }

    out
    {
       return 42;
    }
}

Explicit calling: void in_CoolThing(int); int out_CoolThing(); 
Proper "Property rewrite" can be implemented.

Property CoolThing looks like code contract for 
_privateCoolThing. So it's maybe + or -.

At all, it looks like C# style in D Way.

--no-parenthesis for current behaviour for non-property functions.
Jan 27 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 27 January 2013 at 11:18:01 UTC, sclytrack wrote:
 On Sunday, 27 January 2013 at 10:54:05 UTC, SomeDude wrote:
 On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis 
 wrote:
 I hate optional parentheses with a passion

 - Jonathan M Davis

Same here.

In Delphi they are also optional and nobody uses them. However, everybody else doesn't use them.

Delphi has no real functional capabilities.
Jan 27 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
On Sunday, 27 January 2013 at 12:07:35 UTC, Jacob Carlborg wrote:
 Won't this conflict with contracts, which also uses the "in" 
 and "out" keywords?

As suggestion:
Property CoolThing looks like code contract for 
_privateCoolThing. So it's maybe + or -.


At all, it looks like C# style in D Way.


Jan 27 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 27 January 2013 at 10:54:05 UTC, SomeDude wrote:
 On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis 
 wrote:
 I hate optional parentheses with a passion

 - Jonathan M Davis

Same here.

If that's the level of abstraction on which you want to discuss about optional parentheses, then I could say that "I love optional parentheses", and since "Love conquers all", my argument would win against your argument. But, joking aside, I think that all hate against optional parentheses stems from the increase of ambiguity they indisputably cause. However, let's imagine a future where your perfect D IDE paints function calls red, and variables blue. Then, it will be obvious to you which identifiers are variables and which are function calls based on their color. In this situation it will feel silly to have to write those empty parentheses, because they don't make the code any less ambiguous (it's already perfectly unambiguous because of the colors) and, infact, those empty parentheses make the code (a bit) harder to read.
Jan 27 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 13:24:31 UTC, TommiT wrote:
 But, joking aside, I think that all hate against optional 
 parentheses stems from the increase of ambiguity they 
 indisputably cause. However, let's imagine a future where your 
 perfect D IDE paints function calls red, and variables blue. 
 Then, it will be obvious to you which identifiers are variables 
 and which are function calls based on their color. In this 
 situation it will feel silly to have to write those empty 
 parentheses, because they don't make the code any less 
 ambiguous (it's already perfectly unambiguous because of the 
 colors) and, infact, those empty parentheses make the code (a 
 bit) harder to read.

If we require clever IDE to distinguish visually something as basic as data semantics and callable semantics it is an indicator language design is screwed. Relying on IDE features is what made Java unusable for expressive, robust code. I may use an IDE help when I need to learn architecture level connections in new project, but at scope level semantics for reader should be perfectly clear and unambiguous even if opened in notepad. 2 cents from vim user and optional parens hater here.
Jan 27 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 27 January 2013 at 13:16:59 UTC, Timon Gehr wrote:
 On 01/27/2013 12:35 PM, deadalnix wrote:
 On Sunday, 27 January 2013 at 11:18:01 UTC, sclytrack wrote:
 On Sunday, 27 January 2013 at 10:54:05 UTC, SomeDude wrote:
 On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis 
 wrote:
 I hate optional parentheses with a passion

 - Jonathan M Davis

Same here.

In Delphi they are also optional and nobody uses them. However, everybody else doesn't use them.

Delphi has no real functional capabilities.

What about scala?

I'm not a scala specialist (however, one of my coworker is, so I'll ask him tomorrow) but my understanding is that that autocall functionality in scala is more limited than in D.
Jan 27 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 27 January 2013 at 13:24:31 UTC, TommiT wrote:
 But, joking aside, I think that all hate against optional 
 parentheses stems from the increase of ambiguity they 
 indisputably cause. However, let's imagine a future where your 
 perfect D IDE paints function calls red, and variables blue.

That is not good because in functional style, you manipulate function like variable.
Jan 27 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
 On Sunday, 27 January 2013 at 13:24:31 UTC, TommiT wrote:
 But, joking aside, I think that all hate against optional 
 parentheses stems from the increase of ambiguity they 
 indisputably cause. However, let's imagine a future where your 
 perfect D IDE paints function calls red, and variables blue. 
 Then, it will be obvious to you which identifiers are 
 variables and which are function calls based on their color. 
 In this situation it will feel silly to have to write those 
 empty parentheses, because they don't make the code any less 
 ambiguous (it's already perfectly unambiguous because of the 
 colors) and, infact, those empty parentheses make the code (a 
 bit) harder to read.

If we require clever IDE to distinguish visually something as basic as data semantics and callable semantics it is an indicator language design is screwed. Relying on IDE features is what made Java unusable for expressive, robust code. I may use an IDE help when I need to learn architecture level connections in new project, but at scope level semantics for reader should be perfectly clear and unambiguous even if opened in notepad. 2 cents from vim user and optional parens hater here.

You're being an extremist here. From a vim user and automagic function call hater as well ;) First many reliable code have been written in Java. Quite a lot of it in fact. And refusing IDE help make no real sense. Even vim is an IDE, and not a simple editor.
Jan 27 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
 If we require clever IDE to distinguish visually something as 
 basic as data semantics and callable semantics it is an 
 indicator language design is screwed.

Why is it an indicator of that?
 I may use an IDE help when I need to learn architecture level 
 connections in new project, but at scope level semantics for 
 reader should be perfectly clear and unambiguous even if opened 
 in notepad.

Notepad opens text files. There is nothing that says that the source files of X programming language must be text files. It's just a convention, not a law or a real limitation in designing languages. Therefore you can't assume that an X source file can be opened and read with notepad. Someone might design a language that wouldn't rely on those symbols that just happen to be found on keyboards, but instead, relied more on text formatting and colors.
Jan 27 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 13:56:53 UTC, deadalnix wrote:
 You're being an extremist here. From a vim user and automagic 
 function call hater as well ;)

 First many reliable code have been written in Java. Quite a lot 
 of it in fact. And refusing IDE help make no real sense. Even 
 vim is an IDE, and not a simple editor.

Probably, but that is a result of general mainstream moving to IDE-reliance. You need to sound somewhat radical to be noticed :) I did not say Java is not _reliable_. I have said it is not _expressive_ on language level and relies on boilerplate generation by IDE for something as basic as properties. I do not use vim as an IDE - no plugins, no clever macros, no ctags etc. Any editor with file list, syntax highlighting and tabs works for me; it just happens that it is more convenient to use vim when you mostly do console stuff anyway. That may come from the fact of having most commercial experience in large teams with huge legacy codebases - readability and support issues take there >90% of time and efforts, contrary to actually coding. Made me interested in languages that do enforce such stuff at language level.
Jan 27 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 14:11:13 UTC, TommiT wrote:
 On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
 If we require clever IDE to distinguish visually something as 
 basic as data semantics and callable semantics it is an 
 indicator language design is screwed.

Why is it an indicator of that?

Because it fails to maintain and control semantics on its own.
 Notepad opens text files. There is nothing that says that the 
 source files of X programming language must be text files. It's 
 just a convention, not a law or a real limitation in designing 
 languages.

Text is still most efficient form of providing information. Please call me back when something better will be invented. Then we can speak about minimal editing environment for it.
Jan 27 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
I think that "property as contract for accessing to variable" is 
good point. Maybe we have lack proper terminology, but idea is 
good.
Also it is can be pointed as "property itself - is static 
contract to accessing variable".

class A{
    private int i;
    int foo{
        out out(result){assert(result<=0);}body{return i; }
        in(int v)in{assert(v<=0);}out{assert(foo<=0);}body{ i = 
 v; }
    }
}


class A { private int i; int foo { out{assert( value<=0);}body{return i; } in{assert( value<=0);}body{ i = value; } } } value - in getter it's return value; value - in setter it's param value; void type is not allowed. In theory, property always have only one in/out parameter of same type and performs lightweight actions.
Jan 27 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 27 January 2013 at 14:26:20 UTC, Andrei Alexandrescu 
wrote:
 The same goes about C#, which was designed from day 1 assuming 
 resources are available for dedicated tooling support. It would 
 have evolved differently otherwise, and I assume many people 
 would have a dimmer view of either Java or C# if they had to 
 use it with vim and emacs.

That is kind of my point : such language is made for tooling. With the 2 side of the medal : tooling is great, because language have been made with tooling in mind, but coding without tooling is not the best experience. Not that tremendous efforts are put now to introduce tooling in C++, and results are not as good as they are in Java/C#, simply because C++ is tooling hostile. I know resource are a factor. But clearly not the only one. Doing some tooling on Java is braindead simple, the compiler provide everything you need to reuse it/parts of it.
Jan 27 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 27 January 2013 at 14:14:18 UTC, Dicebot wrote:
 Text is still most efficient form of providing information. 
 Please call me back when something better will be invented. 
 Then we can speak about minimal editing environment for it.

Okay, here's what I invented in 5 minutes that would be better than plain text: * Arguments to a function call would go, instead of inside parentheses, inside a box with a solid, black border and some nice and unique background color. * Template arguments would go in a box with a hatched border line and a different background color. * Blocks are, instead of surrounded by braces, indicated by this thing that looks like a tall, black, thin, right-opening square bracket that spans the whole block and sits directly to the left of the left-most characters of the statements inside the block. * Instead of having '*' indicate both "multiply" and "dereference", invent and use a new symbol that means "dereference". The same goes for all symbols, like '&', '!', '~', ' ', that don't have a universally defined meaning that corresponds to its meaning in language X. In order to input those "things that are not symbols found on your keyboard", you'd either need to learn keyboard shortcuts by heart, or use a custom keyboard, which is what tv and movie editors have done for 20 years with their Avid keyboards. Most other creative jobs require custom tools for performing the craft, why not programming?
Jan 27 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 15:09:10 UTC, TommiT wrote:
 On Sunday, 27 January 2013 at 14:14:18 UTC, Dicebot wrote:
 Text is still most efficient form of providing information. 
 Please call me back when something better will be invented. 
 Then we can speak about minimal editing environment for it.

Okay, here's what I invented in 5 minutes that would be better than plain text: * Arguments to a function call would go, instead of inside parentheses, inside a box with a solid, black border and some nice and unique background color. * Template arguments would go in a box with a hatched border line and a different background color. * Blocks are, instead of surrounded by braces, indicated by this thing that looks like a tall, black, thin, right-opening square bracket that spans the whole block and sits directly to the left of the left-most characters of the statements inside the block. * Instead of having '*' indicate both "multiply" and "dereference", invent and use a new symbol that means "dereference". The same goes for all symbols, like '&', '!', '~', ' ', that don't have a universally defined meaning that corresponds to its meaning in language X. In order to input those "things that are not symbols found on your keyboard", you'd either need to learn keyboard shortcuts by heart, or use a custom keyboard, which is what tv and movie editors have done for 20 years with their Avid keyboards. Most other creative jobs require custom tools for performing the craft, why not programming?

And how it is any better? Also D sources are unicode, so last two are possible just now and you need no special keyboard for it. Still the same good old text.
Jan 27 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 27 January 2013 at 15:22:34 UTC, Dicebot wrote:
 And how it is any better? Also D sources are unicode, so last 
 two are possible just now and you need no special keyboard for 
 it. Still the same good old text.

I don't know if what I invented is any better, but my attempt was to make something that's easier to read and less ambiguous than plain text. For example parenthesis would be used only to define the order in which expressions are evaluated, and _not_ to indicate a section of arguments. But are you really arguing that: "there can be nothing better than plain text for programmers to declare their intent". I wonder why we even have graphic operating systems, if graphic elements don't make thing easier to use and understand. To me, saying that "D is bad language, because in order to most effectively write and understand the code requires some dedicated software" is like saying "Avid is a bad editing software, because using it most effectively requires some custom keyboard". You can write and understand D code, where parentheses of nullary function calls have been omitted, in notepad - it just may not be most optimal environment. Just like you can use Avid with a regular keyboard, it just may not be most optimal to do so (unless you remember all the keys by heart already).
Jan 27 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 27, 2013 at 04:09:09PM +0100, TommiT wrote:
[...]
 Most other creative jobs require custom tools for performing the
 craft, why not programming?

Because it's not *necessary*. Having a universal representation has many advantages, *independence* from custom tools, scriptability, testability, etc.. Independence from specialized tools, contrary to popular opinion, is a very good thing. Having a universal representation like text lets *anyone* write tools for it easily, and more importantly, tools that can work with more than just that specific representation. This is incentive for people to actually invest the effort to make said tools, because the target market is much wider (==lower risk, greater ROI). It also lets more tools than the creators of the thing being represented thought of to be used for manipulating it -- i.e., saves them the effort of reinventing an entire ecosystem, you just leverage what's already out there. Having specialized representations means that far fewer tools can be used for manipulating it, and these tools must be specifically made for the job. Why artificially limit yourself in this way, when generic formats and generic tools are far more useful? Always reminds me of the difficulty of automating the test of GUI apps. You need specialized software to record interactions and replay them, whereas with a text-based interface, you can *generate* test cases that no human has ever done before, thereby making it possible to have more complete coverage than would be possible with any record/replay-based system. GUI apps are also non-scriptable, which greatly limits their usability in automated environments. Recorded GUI scripts are also usually in a non-interoperable format, which makes sharing / editing by others, etc., more difficult than necessary. Obligatory quote: A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen I see many more disadvantages to things like colors, fonts, reliance on specific tools, than advantages. Things that artificially limit themselves for no good reason other than convenience are rarely worth the trouble. (Caveat: I'm another slobbering vim fanatic. I don't even use syntax highlighting. So you may take a big grain of salt with everything I say. :-P) T -- The richest man is not he who has the most, but he who needs the least.
Jan 27 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 15:42:40 UTC, TommiT wrote:
 On Sunday, 27 January 2013 at 15:22:34 UTC, Dicebot wrote:
 And how it is any better? Also D sources are unicode, so last 
 two are possible just now and you need no special keyboard for 
 it. Still the same good old text.

I don't know if what I invented is any better, but my attempt was to make something that's easier to read and less ambiguous than plain text. For example parenthesis would be used only to define the order in which expressions are evaluated, and _not_ to indicate a section of arguments. But are you really arguing that: "there can be nothing better than plain text for programmers to declare their intent". I wonder why we even have graphic operating systems, if graphic elements don't make thing easier to use and understand. To me, saying that "D is bad language, because in order to most effectively write and understand the code requires some dedicated software" is like saying "Avid is a bad editing software, because using it most effectively requires some custom keyboard". You can write and understand D code, where parentheses of nullary function calls have been omitted, in notepad - it just may not be most optimal environment. Just like you can use Avid with a regular keyboard, it just may not be most optimal to do so (unless you remember all the keys by heart already).

More noise -> not easier to read. It may has a merit when designing grammar unambiguous for reader with limited symbol count is impossible but otherwise simple unambiguous representation beats complex one. Also your proposal is not very different from plain text, it is about on the level of syntax highlighting. We do have graphic operating systems and power users still do use consoles/shells for advanced operating system-related work. Because graphic elements are easier to understand, but harder (less efficient) to use. I am perfectly fine with relaxed mouse clicking when I am browsing or watching films or whatever, but when I do work - please, give me a pair of my trusted text shells. I don't know what Avid is but if it requires custom keyboard for proper usage - it is either bad or targeted to users with weak computer competence (and googling shows it is some audio editing stuff, this second option is likely).
Jan 27 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 27 January 2013 at 15:59:42 UTC, Dicebot wrote:
 I don't know what Avid is but if it requires custom keyboard 
 for proper usage - it is either bad or targeted to users with 
 weak computer competence (and googling shows it is some audio 
 editing stuff, this second option is likely).

I was referring to Avid video editing software, which has been used for pretty much all movies and tv series made since 1990. There you can see the custom keyboard in its natural environment: http://meganandtimmy.com/wp-content/uploads/2012/04/Avid.jpeg But this is getting really far from the subject now.
Jan 27 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
 ... but at scope level semantics for reader should be perfectly 
 clear and unambiguous even if opened in notepad.

I think we have been throwing the term ambiguous around too carelessly. Obviously code must be semantically unambiguous when viewed in a Notepad. I don't think that's an issue with optional parentheses - the issue is just that it's "not as easy to read", which I don't think means the same as ambiguous (I'm sure about all english words though). "Not as easy to read" shouldn't sound nearly as bad as ambiguous - it's just a little inconvenience that can be gotten rid of by using an IDE that does semantic colorization.
Jan 27 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 17:19:15 UTC, TommiT wrote:
 On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
 ... but at scope level semantics for reader should be 
 perfectly clear and unambiguous even if opened in notepad.

I think we have been throwing the term ambiguous around too carelessly. Obviously code must be semantically unambiguous when viewed in a Notepad. I don't think that's an issue with optional parentheses - the issue is just that it's "not as easy to read", which I don't think means the same as ambiguous (I'm sure about all english words though). "Not as easy to read" shouldn't sound nearly as bad as ambiguous - it's just a little inconvenience that can be gotten rid of by using an IDE that does semantic colorization.

"easy to read" == "I can find part of code that interests me easily" "unambiguous" == "I can understand semantics of code I have just read with as little additional context as possible" Ambiguity is mentioned often because there is one for compiler and one for programmer. Those two are sometimes similar but rather different in nature.
Jan 27 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
I was just working on some work code and noticed this line that I 
wrote a while ago:

public  property string userId(string file = __FILE__, size_t 
line = __LINE__) {


That's a getter, I always use it "getUser(userId);" etc..... but 
it "takes" two arguments.

If we require getters to have zero arguments, it will break this, 
and that will annoy me. We need to be careful about arbitrarily 
deciding something doesn't make sense and restricting it when 
there's no real technical reason for it.


(Wondering why I did this? If you aren't logged in, this throws a 
Not Logged In Exception. The file and line are passed to the 
exception constructor, meaning then the error message will tell 
me exactly where I forgot the nicer login check.

After wasting cumulative hours on similar problems in earlier 
iterations, I put this in there to eliminate that time sink.)
Jan 27 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 28, 2013 00:18:15 Adam D. Ruppe wrote:
 I was just working on some work code and noticed this line that I
 wrote a while ago:
 
 public  property string userId(string file = __FILE__, size_t
 line = __LINE__) {
 
 
 That's a getter, I always use it "getUser(userId);" etc..... but
 it "takes" two arguments.
 
 If we require getters to have zero arguments, it will break this,
 and that will annoy me. We need to be careful about arbitrarily
 deciding something doesn't make sense and restricting it when
 there's no real technical reason for it.
 
 
 (Wondering why I did this? If you aren't logged in, this throws a
 Not Logged In Exception. The file and line are passed to the
 exception constructor, meaning then the error message will tell
 me exactly where I forgot the nicer login check.
 
 After wasting cumulative hours on similar problems in earlier
 iterations, I put this in there to eliminate that time sink.)

I think that one of two things would be likely to happen were property to stay and properly enforce that it be called with no parens: 1. Your function would be illegal because it had too many arguments. 2. It would be legal, but you could never call it with any arguments for file or line except the defaults, because there would be no syntactic way to do so. But then again, if all you want is a getter and not a setter, and we allow optional parens to continue (which appears to be the case), then you wouldn't have to declare it as property to get the syntax that you want. It just wouldn't be possible to guarantee that you could swap it out for a variable later without breaking code, since it would be possible for someone to call it with parens. - Jonathan M Davis
Jan 27 2013
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 24 Jan 2013 03:34:42 -0500, 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.

Disagree. property serves a very good purpose -- specifying intent. If the intention of a function is to be used as a dynamic field, use property, otherwise do not. Whether or not parentheses should be required on non- property functions, I've given up that struggle. It's not too terrible, and the benefits are difficult to argue against. But please, please, PLEASE do not let normal functions be called as setters. If we get rid of property, we are back to this. Your simple requirements will leave too many functions open to abuse. When you take away property, you take away the expression power of an API designer. I contend that the issue with property was that it was half-implemented. When a half-implemented feature is used for 4 years, it leads to confusion when it doesn't work as specified. In other words, we asked you to build a fence. You built one, but didn't finish it, left a gaping hole. Then you complain about how the fence was useless. I would be satisfied with Kenji's implementation. As I understand it: property on a getter would mean implicit calling of the function. property on a setter would mean calling x = y as x(y). property functions could not be called like normal functions. Parentheses are optional on normal no-arg functions when used as getters. Normal single arg or variadic functions are NOT ALLOWED to be used as setters. Do it. I think 99% of the people here would be OK with this. -Steve
Jan 27 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/28/2013 06:22 AM, Steven Schveighoffer wrote:
 ...

 I would be satisfied with Kenji's implementation.  As I understand it:

  property on a getter would mean implicit calling of the function.
  property on a setter would mean calling x = y as x(y).
  property functions could not be called like normal functions.
 Parentheses are optional on normal no-arg functions when used as getters.
 Normal single arg or variadic functions are NOT ALLOWED to be used as
 setters.
 ...

This proposal unfortunately does not work too well because of UFCS.
Jan 28 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-28 18:07, Steven Schveighoffer wrote:

 Another possibility is to only define  property for setters.  This is
 something I've come to realize that if we are simply going to allow
 omittable parens on getters, there is no functional value to  property
 on them except for the rare case of a delegate property.  That was
 always one of those things where I think too much emphasis was on that
 as a reason for  property existence, it's very rare.

I think property adds clarity and shows intent. For example, now that we have UDA's I have create a struct called "attribute" which I use as an attribute for other structs to should be attributes: struct attribute {} attribute struct foo {} foo int a; Here attribute shows the intent. This is also why I like to have explicit interfaces and abstract classes compared with C++ which doesn't not. -- /Jacob Carlborg
Jan 28 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 28, 2013 at 12:22:01AM -0500, Steven Schveighoffer wrote:
[...]
 Disagree.   property serves a very good purpose -- specifying
 intent.  If the intention of a function is to be used as a dynamic
 field, use  property, otherwise do not.
 
 Whether or not parentheses should be required on non- property
 functions, I've given up that struggle.  It's not too terrible, and
 the benefits are difficult to argue against.
 
 But please, please, PLEASE do not let normal functions be called as
 setters.  If we get rid of  property, we are back to this.  Your
 simple requirements will leave too many functions open to abuse.
 When you take away  property, you take away the expression power of
 an API designer.
 
 I contend that the issue with  property was that it was
 half-implemented.  When a half-implemented feature is used for 4
 years, it leads to confusion when it doesn't work as specified.
 
 In other words, we asked you to build a fence.  You built one, but
 didn't finish it, left a gaping hole.  Then you complain about how
 the fence was useless.
 
 I would be satisfied with Kenji's implementation.  As I understand it:
 
  property on a getter would mean implicit calling of the function.
  property on a setter would mean calling x = y as x(y).
  property functions could not be called like normal functions.
 Parentheses are optional on normal no-arg functions when used as getters.
 Normal single arg or variadic functions are NOT ALLOWED to be used
 as setters.
 
 Do it.  I think 99% of the people here would be OK with this.

+1. T -- May you live all the days of your life. -- Jonathan Swift
Jan 27 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 23:34:59 UTC, Timon Gehr wrote:
 In order to do that, it is necessary aware of the precise 
 definitions, or at least specifications, of referenced 
 declarations in any case. So by your definition, the current 
 function call syntax is "unambiguous".

Sure, it is for compiler. And it for me if I check the definition of symbol. But without going to some other source file and looking up definition there is no way to guess if this: ----- auto ret = something.anything; ----- ..actually does anything else but reassigning a field to a variable. In my personal experience time lost to check such stuff out is much more than time saved by fast and convenient parens-less coding. Thus the attitude.
Jan 28 2013
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Sat, 26 Jan 2013 16:29:16 -0000, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 1/26/13 8:21 AM, Jacob Carlborg wrote:
 On 2013-01-25 22:20, Andrei Alexandrescu wrote:

 That's right with the amendment that we're looking for a solution, not
 pushing one. Even the title of the thread is a question.

 Clearly properties are good to have. In an ideal world we wouldn't need
 a keyword for them and we'd have some simple rules for determining
 property status (especially when it comes to writes). If syntactic help
 is necessary, so be it. We want to make the language better, not worse.

It's always possible to avoid keywords in favor of syntax. Example: Declaring a getter: int foo {} Just as a regular function declaration but without the parentheses. Declaring a setter: void foo= (int value) {} Append an equal sign to the function name.

This is interesting. I wonder how to make it work for UFCS functions (which _do_ have one argument).

Do the c# thing and use 'this'? i.e. int foo(this Person p) {} void foo= (this Person p, int value) {} R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Jan 28 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 28 January 2013 at 08:14:45 UTC, Dicebot wrote:
 Sure, it is for compiler. And it for me if I check the 
 definition of symbol.

However, as long as we have properties *at all* you'd have to check it. If we removed optional parens and put in C# style property syntax, it is still possible .anything is a function call.
Jan 28 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 13:30:33 UTC, Adam D. Ruppe wrote:
 On Monday, 28 January 2013 at 08:14:45 UTC, Dicebot wrote:
 Sure, it is for compiler. And it for me if I check the 
 definition of symbol.

However, as long as we have properties *at all* you'd have to check it. If we removed optional parens and put in C# style property syntax, it is still possible .anything is a function call.

No, I am repeating this again and again - when I see a property I need to think it is a variable. It is intended fooling of the reader and reason to have properties. Thus no checking in that case, I just assume it is a field or variable or anything like that. And if I'll spend few days debugging the case that comes down to my colleague has designed a property that does not behave like a field - I'll go and politely ask to stop doing this. May be also will punch him. Problem solved.
Jan 28 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Monday, 28 January 2013 at 13:34:33 UTC, Dicebot wrote:
 And if I'll spend few days debugging the case that comes down 
 to my colleague has designed a property that does not behave 
 like a field - I'll go and politely ask to stop doing this.

Do you consider a dynamic arrays' length property to be a good, properly designed property: array.length = 7; It does behave like a field, but it's got pretty serious side effects that you just need to know about. And, I don't see much point in having properties that are not allowed to have any side-effects.
Jan 28 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 16:45:57 UTC, TommiT wrote:
 Do you consider a dynamic arrays' length property to be a good, 
 properly designed property:

No.
 And, I don't see much point in having properties that are not 
 allowed to have any side-effects.

Then you need something other than properties.
Jan 28 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Jan 2013 11:31:33 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 01/28/2013 06:22 AM, Steven Schveighoffer wrote:
 ...

 I would be satisfied with Kenji's implementation.  As I understand it:

  property on a getter would mean implicit calling of the function.
  property on a setter would mean calling x = y as x(y).
  property functions could not be called like normal functions.
 Parentheses are optional on normal no-arg functions when used as  
 getters.
 Normal single arg or variadic functions are NOT ALLOWED to be used as
 setters.
 ...

This proposal unfortunately does not work too well because of UFCS.

As many have stated in the past, UFCS getter properties can annotate their "this" argument: property void by5(this int x) { return x * 5;} by5 = 1; // error Another possibility is to only define property for setters. This is something I've come to realize that if we are simply going to allow omittable parens on getters, there is no functional value to property on them except for the rare case of a delegate property. That was always one of those things where I think too much emphasis was on that as a reason for property existence, it's very rare. -Steve
Jan 28 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 16:59:40 UTC, Andrei Alexandrescu 
wrote:
 Wait, so you're against any writable properties? Maybe there's 
 a confusion somewhere.

 Andrei

Ah, yes, there is a confusion between "side-effect" from the pure function point of view and "side-effect" from property functionality point of view. I'd say that property setter should be a pure function with one exception : it is allowed to changed "this" fields. No global state changes, no calls to impure global functions, not even calls to "this" non-property functions.
Jan 28 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Monday, 28 January 2013 at 16:50:27 UTC, Dicebot wrote:
 And, I don't see much point in having properties that are not 
 allowed to have any side-effects.

Then you need something other than properties.

I think you're putting too much faith on the power of convention and on the similarity between your's and everybody else's notions of how much side effects a settable property can have while not giving the user any surprises. Let's say your type has three properties: #1: start_time #2: end_time #3: duration Changing any one of those properties must (logically) change at least one other property. Therefore, you can't just pretend that properties are simple data fields.
Jan 28 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 17:14:31 UTC, TommiT wrote:
 On Monday, 28 January 2013 at 16:50:27 UTC, Dicebot wrote:
 And, I don't see much point in having properties that are not 
 allowed to have any side-effects.

Then you need something other than properties.

I think you're putting too much faith on the power of convention and on the similarity between your's and everybody else's notions of how much side effects a settable property can have while not giving the user any surprises. Let's say your type has three properties: #1: start_time #2: end_time #3: duration Changing any one of those properties must (logically) change at least one other property. Therefore, you can't just pretend that properties are simple data fields.

That is no different from volatile variables. My notion is at least same as C# guideline authors, so it should be not that rare. It all comes from "property == variable" mantra.
Jan 28 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Monday, 28 January 2013 at 17:30:40 UTC, Dicebot wrote:
 Let's say your type has three properties:
 #1: start_time
 #2: end_time
 #3: duration

 Changing any one of those properties must (logically) change 
 at least one other property. Therefore, you can't just pretend 
 that properties are simple data fields.

That is no different from volatile variables.

If you think my example of {start_time, end_time, duration} represents proper use of properties, then I don't see why you oppose array.length. To me it seems like the same thing. Array has some length, and you can change it by changing its length property. T represents a certain time range, and you can change it by changing any of its three properties {start_time, end_time, duration} which describe that time range.
 My notion is at least same as C# guideline authors, so it 
 should be not that rare. It all comes from "property == 
 variable" mantra.

I'm just saying that when you read some code written by some person X, you can't rely on person X having the same notion of what properties should be as you do. For this reason you can't only read the documentation of methods and skip reading the documentation of properties, because properties may do/change things that you wouldn't have made them do/change.
Jan 28 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 17:52:45 UTC, TommiT wrote:
 If you think my example of {start_time, end_time, duration} 
 represents proper use of properties, then I don't see why you 
 oppose array.length. To me it seems like the same thing. Array 
 has some length, and you can change it by changing its length 
 property. T represents a certain time range, and you can change 
 it by changing any of its three properties {start_time, 
 end_time, duration} which describe that time range.

T changes its inner encapsulated states. Period. It is no different that properties that calculate result on the fly, like range.empty (which is good property usage). Array.length allocates. Takes from some global resources, takes some considerable time, calls some global allocating function. For me it is a crucial difference that pushes symbol to the world of functions.
Jan 28 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Monday, 28 January 2013 at 18:04:22 UTC, Dicebot wrote:
 T changes its inner encapsulated states. Period. It is no 
 different that properties that calculate result on the fly, 
 like range.empty (which is good property usage).

 Array.length allocates. Takes from some global resources, takes 
 some considerable time, calls some global allocating function.

 For me it is a crucial difference that pushes symbol to the 
 world of functions.

The question "what is or should be a property?" is a question of semantics. I don't see what performance or those implementation details you mentioned have to do with semantics. What if our container type wasn't a dynamic array? Let's say it's a pseudo container that pretends to be a vector of consecutive int values, but in reality it just has two integers which denote the beginning and the end of the range. Now changing the length property of that container takes constant time (it just sets the end value anew).
Jan 28 2013
prev sibling next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Monday, 28 January 2013 at 18:43:19 UTC, Andrei Alexandrescu 
wrote:
 On 1/28/13 1:04 PM, Dicebot wrote:
 On Monday, 28 January 2013 at 17:52:45 UTC, TommiT wrote:
 If you think my example of {start_time, end_time, duration} 
 represents
 proper use of properties, then I don't see why you oppose
 array.length. To me it seems like the same thing. Array has 
 some
 length, and you can change it by changing its length 
 property. T
 represents a certain time range, and you can change it by 
 changing any
 of its three properties {start_time, end_time, duration} which
 describe that time range.

T changes its inner encapsulated states. Period. It is no different that properties that calculate result on the fly, like range.empty (which is good property usage). Array.length allocates. Takes from some global resources, takes some considerable time, calls some global allocating function. For me it is a crucial difference that pushes symbol to the world of functions.

I guess you hate if people want their bigints to assign with a = b. Andrei

widget.height = 100 should be condemned, too - it changes the state of the entire GUI system. Let's face it: there are *no* objective criteria for determining whether a mutator should be a function or property setter.
Jan 28 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 19:43:39 UTC, Jacob Carlborg wrote:
 On 2013-01-28 18:11, Dicebot wrote:
 What about getters and setters and gets and sets a value from a 
 cache?

Would not have made them properties either. It is somewhat similar to cache and const vs logical const issue. But you are right, this is were personal preferences start varying a lot, I don't realistically hope someone will give me language that restrictive in its core for my needs :) Just expressing personal attitude because I am in the hospital, bored and have a crazy amount of free time to chat on newsgroup :) That may sound weird but I do like when core language features are very restrictive and require programmer to express his intentions verbosely. And provide _possibility_ to do cool stuff via advanced clearly separated advanced features. Like safe vs system but for syntactic language features. Not gonna convince anyone but at least pushing it my way makes me feel good :)
Jan 28 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 18:43:19 UTC, Andrei Alexandrescu 
wrote:
 I guess you hate if people want their bigints to assign with a 
 = b.

Have never used bigints. You mean that copy construction upon assignment allocates too? Yes, I do now like this, too, but see no sane to get around this as it will feel unnatural either way. Arrays, however, will not suffer at all from switching to array.resize(42) syntax from array.length = 42 syntax.
Jan 28 2013
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 28 Jan 2013 05:26:43 -0800, Regan Heath <regan netmail.co.nz>  
wrote:

 On Sat, 26 Jan 2013 16:29:16 -0000, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 On 1/26/13 8:21 AM, Jacob Carlborg wrote:
 On 2013-01-25 22:20, Andrei Alexandrescu wrote:

 That's right with the amendment that we're looking for a solution, not
 pushing one. Even the title of the thread is a question.

 Clearly properties are good to have. In an ideal world we wouldn't  
 need
 a keyword for them and we'd have some simple rules for determining
 property status (especially when it comes to writes). If syntactic  
 help
 is necessary, so be it. We want to make the language better, not  
 worse.

It's always possible to avoid keywords in favor of syntax. Example: Declaring a getter: int foo {} Just as a regular function declaration but without the parentheses. Declaring a setter: void foo= (int value) {} Append an equal sign to the function name.

This is interesting. I wonder how to make it work for UFCS functions (which _do_ have one argument).

Do the c# thing and use 'this'? i.e. int foo(this Person p) {} void foo= (this Person p, int value) {} R

Yes, C# uses a 'this' argument as it's first parameters to make it an Extension Method. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Jan 28 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
On Monday, 28 January 2013 at 21:03:04 UTC, Max Samukha wrote:
 Let's face it: there are *no* objective criteria for 
 determining whether a mutator should be a function or property 
 setter.

Yes, but also it's should be a lightweight action (main idea). As proposal: http://forum.dlang.org/post/ydcjggoibjmuuoobgrvq forum.dlang.org And C# Property notes http://msdn.microsoft.com/en-us/library/w86s7x04.aspx http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx and quote
 At all, it looks like C# style in D Way.
 --no-parenthesis for current behaviour for non-property 
 functions.

Jan 28 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 28 January 2013 at 21:43:25 UTC, Andrei Alexandrescu 
wrote:
 On 1/28/13 4:32 PM, Dicebot wrote:
 On Monday, 28 January 2013 at 18:43:19 UTC, Andrei 
 Alexandrescu wrote:
 Arrays, however, will
 not suffer at all from switching to array.resize(42) syntax 
 from
 array.length = 42 syntax.

Well I think this is a given now. So again - time to adjust preferences :o).

My feeling is that the array.length getter/setter problem is affected by the perceived assymetry between the getter and the setter operation. Even more, that feeling is exacerbated by the involvment of a canonical type. People expect some expensive background operations for user-defined, complicated types, but not for canonical types. Properties too, are plagued by this, but at least there the choice is explicitly marked and assumed. As for the a=b bigInts vs the array.length=5 problem: the former operation affects the content of a and b. The latter not only affects the content of array.length, but also the very content of array itself. I know the border is thin, however, it exists at the psychological level, since many will gladly accept reallocation in a=b, but not in array.length=5. Maybe is just the power of habit. Maybe not.
Jan 28 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 21:43:25 UTC, Andrei Alexandrescu 
wrote:
 So maybe it's time to adjust your preferences.

Ye, I know, I speak too much :( Sure, switching to low profile mode.
Jan 29 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Tuesday, 29 January 2013 at 10:26:54 UTC, Dicebot wrote:
 On Monday, 28 January 2013 at 21:43:25 UTC, Andrei Alexandrescu 
 wrote:
 So maybe it's time to adjust your preferences.

Ye, I know, I speak too much :( Sure, switching to low profile mode.

Reason and reasonable trade-off should prevail.
Jan 29 2013
prev sibling next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Monday, 28 January 2013 at 21:54:21 UTC, Michael wrote:
 On Monday, 28 January 2013 at 21:03:04 UTC, Max Samukha wrote:
 Let's face it: there are *no* objective criteria for 
 determining whether a mutator should be a function or property 
 setter.

Yes, but also it's should be a lightweight action (main idea).

I think we need something more measurable than lightweight-ness to justify a language feature.
 As proposal:

 http://forum.dlang.org/post/ydcjggoibjmuuoobgrvq forum.dlang.org

 And C# Property notes
 http://msdn.microsoft.com/en-us/library/w86s7x04.aspx
 http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx

 and quote

 At all, it looks like C# style in D Way.
 --no-parenthesis for current behaviour for non-property 
 functions.


Jan 29 2013
prev sibling next sibling parent "Alvaro" <alvaroSPAMALOTsegura gmail.com> writes:
I agree with Adam's view and I really think  property is a good 
thing.

APIs have to specify their semantics and clearly distinguish 
properties from functions, which may be implemented similarly but 
*mean* different things. Basically a property is a *thing* or a 
characteristic, normally a noun, whereas a property is an action, 
normally a verb.

As a special case, a property can be a delegate or function, and 
calling it with () would apply the parens to the delegate (which 
the user is explicitly calling), but not to the property.

Properties as they are can also be used to emulate "indexed 
properties", as in other languages. If a property's type is a 
struct that implements [] and []= then we can do:

image.pixels[x,y] = Rgb(255,0,0);

And yes, I think properties should always be called ["used" I 
would rather say] without parens, and functions always be called 
with parens. Isn't it like this in other languages, e.g. C#, BTW?

But anyway as I don't develop the compiler, I speak from a 
distance, and I'm not aware of the implementation complications 
there may be...



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.

Jan 29 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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.

Progressively, I start considering this as a not-so-bad idea. Anyway, the issue of property should be cleared up. The current state of affairs is poisoning the language.
Jul 19 2013
prev sibling next sibling parent "Stian Pedersen" <stian.pedersen gmail.com> writes:
To add to the mess - or maybe suggest a new approach, what about:

class A
{
     int foo();
     void foo=(int a);
     private foo_;
}

Then a.foo = 42; calls the foo= method. No other conversions from 
a=b to a method invocation.

It may be suggested in one of these 46 pages which I haven't 
read. And it'll probably break a lot of stuff.
Aug 10 2013
prev sibling next sibling parent "Stian Pedersen" <stian.pedersen gmail.com> writes:
Missing an int before foo_ there.
Aug 10 2013
prev sibling next sibling parent "JS" <js.mdnq gmail.com> writes:
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.

Here is my mindless proposal after reading some of the posts. 1. Properties are data. Cannot be called with parenthesis, unless it returns a delegate, in which case the delegate is called. The address of a property is invalid(possibly gotten through a trait). 2. Properties cannot be used in UFCS calls, unless they return a delegate. Only UFCS chaining allows for parenthesis-less calls. e.g., (). -> . Properties are great, C# doesn't have any issues with them... so why should D? From the little reading, the best I can tell is that the issue comes directly from UFCS and trying to avoid using parenthesis. Conflating the issue between properties and UFCS isn't an issue with properties or UFCS but with distinguishing between them. UFCS wants property like behavior but then that causes problems with properties themselves. Properties want function call behavior but then that makes them look like functions, yet this defeats the purpose of a property. Alternative, use a different syntax for chaining UFCS's. Instead of using ()., use something like func1:func2:func3:func4; where : seems to be a somewhat unused symbol... ~, >, >>, or others could potentially be used. Such a symbol AUTOMATICALLY is replaced with `().` since everything is a function call. (no properties can exist in the chain unless they return delegates, in which case the delegate is uses)
Aug 10 2013
prev sibling next sibling parent "Borislav Kosharov" <boby_dsm abv.bg> writes:
On Saturday, 10 August 2013 at 10:29:51 UTC, Stian Pedersen wrote:
 To add to the mess - or maybe suggest a new approach, what 
 about:

 class A
 {
     int foo();
     void foo=(int a);
     private foo_;
 }

 Then a.foo = 42; calls the foo= method. No other conversions 
 from a=b to a method invocation.

 It may be suggested in one of these 46 pages which I haven't 
 read. And it'll probably break a lot of stuff.

I like this. It is something like in Ruby. And Ruby also has some meta programming support and there are these 3 "templates" attr_reader, attr_writer and attr_accessor (both of the previous together). And one could write (in Ruby): class Foo attr_writer :name, :number #Ruby has symbols(something like enums) end And translates to: class Foo def name=(name) name = name //the name means class private variable in Ruby end def number=(number) number = number //and they don't need to be declared(dynamicly typed lang) end end So in D those 3 attr 'shortcuts' could be implemented with mixin templates. And instead of those 'symbols' they could be just a list of strings. Example: class Foo { mixin Reader!("name", "number"); } And something similar to happen. Although this not solves all property problems it makes writing them shorter. And I have started experimenting with that and it is almost finished, but it is a little different from what I described above. The file is a part of a thing I started working on in D, but here is a direct link(https://github.com/nikibobi/spine-d/blob/master/src/spine/util/property.d) and the files is isolated from the other things. See the unittests for examples.
Aug 10 2013
prev sibling next sibling parent "BLM768" <blm768 gmail.com> writes:
On Saturday, 10 August 2013 at 10:29:51 UTC, Stian Pedersen wrote:
 To add to the mess - or maybe suggest a new approach, what 
 about:

 class A
 {
     int foo();
     void foo=(int a);
     private foo_;
 }

 Then a.foo = 42; calls the foo= method. No other conversions 
 from a=b to a method invocation.

 It may be suggested in one of these 46 pages which I haven't 
 read. And it'll probably break a lot of stuff.

The problem with this approach is that the getter is still operating under the semantics of a method, but, as a property, it should be acting like a field. An approach like this would work: class A {
Aug 10 2013
prev sibling next sibling parent "BLM768" <blm768 gmail.com> writes:
On Saturday, 10 August 2013 at 17:48:34 UTC, BLM768 wrote:
 On Saturday, 10 August 2013 at 10:29:51 UTC, Stian Pedersen 
 wrote:
 To add to the mess - or maybe suggest a new approach, what 
 about:

 class A
 {
    int foo();
    void foo=(int a);
    private foo_;
 }

 Then a.foo = 42; calls the foo= method. No other conversions 
 from a=b to a method invocation.

 It may be suggested in one of these 46 pages which I haven't 
 read. And it'll probably break a lot of stuff.

The problem with this approach is that the getter is still operating under the semantics of a method, but, as a property, it should be acting like a field. An approach like this would work: class A {

pressed space with the "Send" button focused. Continuing... class A { property int foo(); property void foo=(int a); //etc. } However, it doesn't offer any significant advantage over the current property syntax other than providing a clearer distinction between getters and setters, which is only important when dealing with UFCS, as pointed out in an earlier post.
Aug 10 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 August 2013 13:27, JS <js.mdnq 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.

Here is my mindless proposal after reading some of the posts. 1. Properties are data. Cannot be called with parenthesis, unless it returns a delegate, in which case the delegate is called. The address of a property is invalid(possibly gotten through a trait). 2. Properties cannot be used in UFCS calls, unless they return a delegate. Only UFCS chaining allows for parenthesis-less calls. e.g., (). -> . Properties are great, C# doesn't have any issues with them... so why should D? From the little reading, the best I can tell is that the issue comes directly from UFCS and trying to avoid using parenthesis.

Might be wrong "cause I've only spent 5 minutes looking at it severall months ago" but C#'s properties are just simple getter/setter's, no? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 10 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.

My 2 cents on this, very late in the day. Sorry for the essay, hopefully it'll be worth your time. No fancy new ideas, but I *think* I have a nice solution that keeps everyone happy and avoids nasty corner-cases and ambiguities: 1) non-property functions must be called with parenthesis, *except* on UFCS calls. No assignment call syntax for non-properties. fun1.fun2; //illegal fun1.fun2(); //illegal fun1().fun2; //OK fun1().fun2(); //OK fun1; //illegal fun1(); //OK fun2 = var; //not a function call, but a normal assignment where //possible, e.g. initialising a function pointer. iota(100).map!"a+1".filter!"a%5".writeln; //LEGAL :-) Alternative way of saying it: optional paren for single argument calls in UFCS, enforced parenthesis elsewhere. Reason: No one wants writeln = "Hello World!"; but a lot of people want "Hello World!".writeln; Also, this removes visual ambiguity between the name of a function and it's result. That only really matters with alias/variadic template parameters but it is very annoying there. That will never conflict with UFCS so everyone's happy. Note that in the first two examples, fun1 is *NOT* a UFCS call and therefore cannot be done without parens. Preventing optional parens on non-UFCS stops any possible mixing of optional parenthesis and the unary & operator. 2) property enforces parenthesis-less calling for getters and assignment syntax for setters. No properties with more than one argument allowed. If a property returns a callable, any parenthesis will be applied to the callable Reason: Properties are not for general purpose work. The whole point of them is to be used roughly like variables and this is as close to that as we're gonna get. 3) Getting the address of a function is done with the & operator. Callables must always have parenthesis *except* when: Parenthesis would be optional for an equivalent normal function AND not when the callable is the result of an expression: 42.aDelegate.foo; //OK 42.returnsADelegate.foo; //OK, foo acts on the delegate 42.returnsADelegate().foo; //OK, foo acts on the delegate 42.returnsADelegate()().foo; //OK, foo acts on //the return value of the delegate aDelegate; //illegal aDelegate() //OK "blah".aDelegate; //OK "blah".aDelegate(); //OK auto a = &returnsADelegate; //a is function pointer to //returnsADelegate a; //illegal auto b = a(); //OK, calls a and b is a delegate b; //illegal b(); //OK, calls the delegate. //given some struct Bar that overloads opBinary!"+" and opCall Bar x,y; x; //illegal x(); //opCall (x+y) //does not call opCall (x+y)() //does call opCall Reason: This allows them to be used transparently like normal functions where possible, but removes ambiguity elsewhere. 3a) Explicitly taking the address of a property. Attempting to shoe-horn this in with normal syntax causes hell for the rest. I suggest some magic here, e.g. __traits(propertyGetterAddress, a.prop) and __traits(propertySetterAddress, a.prop) A function pointer to a property must be called as a normal function pointer. auto v = __traits(propertyGetterAddress, a.prop); auto n = v; //n is a function pointer to the getter a.prop, //same as v auto n = v(); //n is equal to the return of the getter a.prop auto h = __traits(propertySetterAddress, a.prop); auto j = h; //j is a function pointer to the setter a.prop //same as h h = 3; //illegal h(3); //OK, equates to a.prop = 3; Reason: This needs to be possible, but using & for it is broken. The most important thing is to keep the syntax of common use-cases clean and unsurprising. ***any other workable syntax for this is ok, __traits is just an (ugly, verbose) example*** Losing all property-ness when working through a function pointer keeps things simple. 4) OPTIONAL: Free functions can be marked as properties, with the same rules applied to them as properties in aggregates, except they must take 1 or 2 arguments instead of 0 or 1. Reason: Free functions and ufcs => good for encapsulation and nice to look at. Is there any reason why not to allow us to declare free properties? These rules should provide the least possible surprise and breakage, as far as I can tell. I don't think personally I would have to alter a single line of my code. What inevitable corner-cases have I missed?
Aug 10 2013
prev sibling parent "Jason den Dulk" <public2 jasondendulk.com> writes:
Part 1 - Ordinary Functions (the rewrite rules)
--------------------------
Not strictly the discussion topic, but it was a big issue and is 
related, so:

Q: Do you think the "property" rewrite rules (ie optional opCall 
operators) are a bad idea.
A: Yes I do
Q: Why?
A1: Look at all the confusion its caused!
A2: Because I have shot myself in the foot too many times because 
of this to be convinced otherwise. Judging from the posts, I am 
not the only one hopping around on one foot.
Q: Accepting that it's here to stay, what can you do about it?
A: Pretend they don't exist and always write expressions the 
"correct" way.

Basically If you're having problems with the "property" rewrite 
rules, then stop trying to use them. Adopt the habit of always 
writing your function calls verbosely (even with UFCS) and your 
problems should go away.

Unless they are going to be gotten rid of entirely, the rewrite 
rules should not be changed. All of the suggestions I've seen 
(including Walter's original one) will only lead to more 
complexity, more special cases, more inconsistency, more 
confusion, and more problems.

Part 2 -  property
--------------------------

A big problem with  property is that people are thinking of them 
as functions, no small part due to the "property" rewrite rules 
discussed above. Even people who suggest that  properties should 
not use opCall still talk about calling properties, as though 
they are functions.

The trick is to stop thinking of properties in terms of 
functions, and to think of them as variables. To "call" a 
property should make as much sense as calling a variable.

Some have mentioned this, and others have hinted at it, but I 
think that it has not been made fully clear.

To illustrate, consider this:

    int v;

v is a reference to a block of memory which is accessed by a 
machine code getter and setter. So

    int a;

is really

     property { int a() { fetch from memory }; int a(int) { write 
to memory } }

When you're declaring a true property, you're still declaring a 
variable, but you're simply providing the complier with 
altertives to the traditional fetch/write instructions.

------------------------------

Here is another (admittedly more complex) way to look at it.

struct {
   int opAssign(int) { ... };
   int opCast!(int) { ... } ;
} Property

Property prop;

You will need to imagine the opCast as an implicit cast for it to 
work, but hopefully you will get what I mean.

Here prop is a variable, so it would be parsed like one by the 
compiler.

The expression "prop = 3" would assign 3 to the contents of prop, 
Which would result in the opAssign (the setter) being called.

In the expression "y = prop++", we get the contents of prop (via 
opCast, the getter), apply the ++ operator to it, and assign the 
result to y.

If prop were an actual integer, the above expressions would work 
exactly the same way.

Using struct for this is a little ugly, so you could say instead:

 property { int prop(int) { ... }; int prop() { ... }; }

A little neater, but would work the same way.

Part 3 - functions returning delegates.
---------------------------------------

When it comes to delegate properties (ie the getter returns a 
delegate), I'm sensing that people are having trouble getting 
their heads around it, always needing to treat it like a special 
case. Let's try to see it in a way that it is not special.

Lets have

     delegate int() f1;

and

      property delegate int() f2() { ... };

In the eyes of the greater world f1 and f2 should work the same 
way.

In the expression y = f1(), we get the contents of f1 (the 
delegate), apply the "()" operator to it, and assign the result 
to y;

In the expression y = f2(), we get the contents of f2 (via the 
getter, which gives us the delegate), apply the "()" operator to 
it, and assign the result to y;

In both cases y is an int.

Recall an eariler statement:

In the expression "y = prop++", we get the contents of prop (via 
opCast, the getter), apply the ++ operator to it, and assign the 
result to y.

Note the similarity. () is like other operators and is no longer 
special.

How does this work for ordinary functions?

     int func()

can be seen as

     auto func = function int()

func is a variable and its contents is the function. The 
expression func() means "get the contents of func (the function) 
an apply () to it (gives int)".

For

     delegate int() delg()

which can be seen as

     auto delg = function (delegate int())()

The expression delg() means "get the contents of delg (the 
function) and apply () to it (gives delegate)", and delg()() 
would apply () to whatever delg() gives and, ultimately, give us 
an int.

----------------------------------

How come people are getting confused about it? That damn optional 
opCall rewrite rule.

Some people probably think that, for functions returning 
delegates, if
    f becomes f()
then
    f() becomes f()()

THIS DOES NOT HAPPEN! Nor should it. Remember that and you should 
be OK. Otherwise consider my suggestion in Part 1.

Part 4 - Answering the original question.
----------------------------------------

Should  property be shot?

No, but it should be reworked

Regards
Jason
Aug 11 2013