www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Make dur a property?

reply "monarch_dodra" <monarchdodra gmail.com> writes:
I was using dur, and as powerful as it is, I *hate* typing:

//----
Thread.sleep(dur!"msecs"(100));
//----

Then, this reminded me of an older thread I started:
Neat: UFCS for integer dot operator suffix
http://forum.dlang.org/thread/uchcycnsvykuojzhuokh forum.dlang.org

And then it struct me:
//----
Thread.sleep(100.dur!"msecs");
//----

Yay! Or even better:
//----
alias msecs = dur!"msecs"
...
Thread.sleep(100.msecs); //Wow. Talk about expressive !!!
//----

Sweet-o! How much cooler can this get?

...

Well, if you are compiling with "-property", the compiler forces 
you to type:
//----
Thread.sleep(100.msecs());
//----

It is *almost* the same thing, but actually not the same at all. 
It shatters the "native" feeling of the suffix notation.

AFAIK, the "-property" switch enforces that non-property 
functions use parenthesis, so removing an " property" attribute 
is potentially breaking. The opposite though is not so true. You 
can add  property to anything, and never break code.

...

So I thought I'd discuss: Would there be a reason to not make dur 
a property? This should impact no-one, but make ufcs usage that 
much more convenient. Can I get the go-ahead to make and document 
the change?

What about making things like msecs public aliases? How do you 
feel about that?
Jan 23 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/23/2013 06:03 PM, monarch_dodra wrote:
 ...

 Well, if you are compiling with "-property", the compiler forces you to
 ...

So don't.
 AFAIK, the "-property" switch enforces that non-property functions use
parenthesis, so removing an " property" attribute is potentially breaking. The
opposite though is not so true. You can add  property to anything, and never
break code.

That is completely nonsensical behaviour. Just ignore -property.
Jan 23 2013
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/23/2013 09:13 AM, Timon Gehr wrote:
 On 01/23/2013 06:03 PM, monarch_dodra wrote:
 ...

 Well, if you are compiling with "-property", the compiler forces you to
 ...

So don't.
 AFAIK, the "-property" switch enforces that non-property functions use
 parenthesis, so removing an " property" attribute is potentially
 breaking. The opposite though is not so true. You can add  property to
 anything, and never break code.

That is completely nonsensical behaviour. Just ignore -property.

+1. Ali
Jan 23 2013
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
23-Jan-2013 21:13, Timon Gehr пишет:
 On 01/23/2013 06:03 PM, monarch_dodra wrote:
 ...

 Well, if you are compiling with "-property", the compiler forces you to
 ...

So don't.
 AFAIK, the "-property" switch enforces that non-property functions use
 parenthesis, so removing an " property" attribute is potentially
 breaking. The opposite though is not so true. You can add  property to
 anything, and never break code.

That is completely nonsensical behaviour. Just ignore -property.

+111 -- Dmitry Olshansky
Jan 23 2013
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
23-Jan-2013 22:57, Nick Sabalausky пишет:
 On Wed, 23 Jan 2013 19:40:02 +0100
 "Adam D. Ruppe" <destructionator gmail.com> wrote:

 On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau
 wrote:
 This sounds OK, but you can still run into the callable issue
 if a normal function returns a callable.

I don't think so because delegates require the parens to call anyway, and so do opCall objects (without the parens, it is just a reference to it).

So you want it to work like this?: void foo() {...} void delegate() {...} bar; foo; // call it

This is a call, arguably bad style
      bar; // don't call it

compile-time error, as statement has no side-effects? (and we have this kind of check even now) -- Dmitry Olshansky
Jan 23 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 1:18 PM, Johannes Pfau wrote:
 Please do not forget the main reason for  property: Returning a
 delegate from a function can become ambiguous without it:

 int a(){return 42;}
 void b() {return&a;}

 auto var = b; //OK
 auto var2 = b(); //is var2 == b or == 42?

 It might be an extreme corner case, but it's inconsistent behavior and
 confusing.

Agreed. I think we should require property only for those cases, and not any others. Andrei
Jan 23 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 5:32 PM, Nick Sabalausky wrote:
 I'd rather not see more "Sometimes the language lets me skip XXXX, and
 sometimes it complains" get introduced into the language. That
 complicates the language and makes the language harder to understand.

 There are cases where that strategy has certainly made sense, but at
 this point I think you're just grasping for ways to justify leaving in
 the non-beneficial "Use either 'foo' or 'foo()', whichever you want,
 anytime you want" sloppiness. And making sure that non-feature can
 remain by introducing more special-cases into the language to patch
 over the problems with the non-feature.

UFCS has effectively buried the case for requiring parens. Andrei
Jan 23 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 1:48 PM, Nick Sabalausky wrote:
 Having the *caller* decide whether something is a property or not makes
 as much sense as having the caller decide the function's name,
 signature and semantics.

No. The caller does get to decide a variety of syntactic aspects of the invocation.
 If anything, that's an issue with template syntax, it has nothing to do
 with properties, let alone the beloved practice of abusing properties
 for the sake of things that clearly are not properties.

The implied assumption here is that if it doesn't have parens it's a property. Well it's a function call. Andrei
Jan 23 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/23/2013 11:40 PM, Nick Sabalausky wrote:
 On Wed, 23 Jan 2013 15:14:21 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/23/13 1:48 PM, Nick Sabalausky wrote:
 Having the *caller* decide whether something is a property or not
 makes as much sense as having the caller decide the function's name,
 signature and semantics.

No. The caller does get to decide a variety of syntactic aspects of the invocation.

Yes, but it's unfortunate that includes a part of the syntax that carries semantic/conceptual implications for something (action or data) that is already *inherently* determined by writer of the *callee*.

Keeping or leaving out the parens has no semantic implications.
 If anything, that's an issue with template syntax, it has nothing
 to do with properties, let alone the beloved practice of abusing
 properties for the sake of things that clearly are not properties.

The implied assumption here is that if it doesn't have parens it's a property. Well it's a function call.

Right, it's a function call. So what in the world do we gain by allowing the caller to make it look like something it isn't? Nothing.

That does not make any sense. It still looks just like a function call, because that is how a function call might look.
Jan 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 03:02, Nick Sabalausky wrote:

 foo.bar() // Perform action
 foo.bar   // Access data

Who says it has to be like this. -- /Jacob Carlborg
Jan 24 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 3:20 AM, Jacob Carlborg wrote:
 On 2013-01-24 03:02, Nick Sabalausky wrote:

 foo.bar() // Perform action
 foo.bar // Access data

Who says it has to be like this.

Agreed. It's an implied, unstated assumption - the most dangerous kind. Andrei
Jan 24 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 07:16 PM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 11:25:38 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 3:20 AM, Jacob Carlborg wrote:
 On 2013-01-24 03:02, Nick Sabalausky wrote:

 foo.bar() // Perform action
 foo.bar // Access data

Who says it has to be like this.

Agreed. It's an implied, unstated assumption - the most dangerous kind.

It's dangerous to *break*, not to follow.

It's somewhat dangerous to assume but not to follow at the same time. No significantly stronger statement can be made, which is why this is a matter of taste.
Jan 24 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 19:16, Nick Sabalausky wrote:

 It's dangerous to *break*, not to follow.

Follow what? There are several languages that don't care if you use parentheses when calling a method. -- /Jacob Carlborg
Jan 24 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 04:45 PM, Johannes Pfau wrote:
 Am Thu, 24 Jan 2013 09:20:44 +0100
 schrieb Jacob Carlborg <doob me.com>:

 On 2013-01-24 03:02, Nick Sabalausky wrote:

 foo.bar() // Perform action
 foo.bar   // Access data

Who says it has to be like this.

.NET guidelines since .NET 1.1 for example: "In general, methods represent actions and properties represent data." (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).

This is not C#.
Jan 24 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 05:56 PM, Johannes Pfau wrote:
 Am Fri, 25 Jan 2013 00:11:24 +0100
 schrieb Timon Gehr <timon.gehr gmx.ch>:

 On 01/24/2013 04:45 PM, Johannes Pfau wrote:
 Am Thu, 24 Jan 2013 09:20:44 +0100
 schrieb Jacob Carlborg <doob me.com>:

 On 2013-01-24 03:02, Nick Sabalausky wrote:

 foo.bar() // Perform action
 foo.bar   // Access data

Who says it has to be like this.

.NET guidelines since .NET 1.1 for example: "In general, methods represent actions and properties represent data." (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).

This is not C#.

I think I misunderstood the question. If the question was whether the parenthesis mark an action as opposed to data access, then my statement is of course void. (But it's a tradition from C that () mark function calls). I thought he meant properties should be used for data access. This is almost by definition: Java used setX /getX, C# formalized that into properties, D took properties from C#. Properties where always used for data access, if you don't use properties for data access but for other things the whole concept doesn't make sense. So in that case "this is C#". ...

I think he meant both. =)
Jan 25 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 5:40 PM, Nick Sabalausky wrote:
 On Wed, 23 Jan 2013 15:14:21 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:

 On 1/23/13 1:48 PM, Nick Sabalausky wrote:
 Having the *caller* decide whether something is a property or not
 makes as much sense as having the caller decide the function's name,
 signature and semantics.

No. The caller does get to decide a variety of syntactic aspects of the invocation.

Yes, but it's unfortunate that includes a part of the syntax that carries semantic/conceptual implications for something (action or data) that is already *inherently* determined by writer of the *callee*.

"Semantic" and "conceptual" sound interesting but are a bit out of context here. We're talking simple syntax here, and in particular an option available to other languages already.
 If anything, that's an issue with template syntax, it has nothing
 to do with properties, let alone the beloved practice of abusing
 properties for the sake of things that clearly are not properties.

The implied assumption here is that if it doesn't have parens it's a property. Well it's a function call.

Right, it's a function call. So what in the world do we gain by allowing the caller to make it look like something it isn't? Nothing.

Never answer your own rhetorical question :o). Andrei
Jan 23 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
24-Jan-2013 06:46, Nick Sabalausky пишет:
 On Wed, 23 Jan 2013 18:38:11 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 The real question is "Is this an action or data?" (And obviously I mean
 when viewed from outside the encapsulation, I don't mean the
 implementation.) Note that the answer to that question is NOT
 subjective to the context of the caller, only the callee. Blindly
 discounting the "conceptual" matter (ie "action or data?") is a
 convenient way contort the issue so that it fits back into the "Call
 with/without parens?" strawman.

These days properties imply an action of, well, obtaining said value. If it's a wrapper as in "return zis variable" something is wrong already.
 There have already been enough problems shown that have arisen as a
 direct result of mistreating the matter of properties as merely
 an "optional paren" syntax matter. You suggest various additional rules
 to patch over those symptoms, but when you consider the very simple,
 time-honored, and frankly very very common, association of:

 foo.bar() // Perform action
 foo.bar   // Read/Write data

The same argument was brought about overloading operators, about overloading functions, etc. In other words the argument is WYSIWYG, but humans inherently think in overloaded notions and take obvious shortcuts just about everywhere. Also what about x.y itself? Unlike in C/C++ you don't know if x is a pointer or not. And so what? Add to this possible static members, D already cuts corners and not at all WYSIWYG. Also see the opDispatch problems as it can be either property or not. property on its own brings a lot of schism. What makes all of the engineering, science etc. domains usable at all - is an optimized/overloaded/shortened vocabulary. In this light extra parens are redundant and thus skipped, end of story. Feel free to impose a coding standard that requires usage of these and see how it goes. -- Dmitry Olshansky
Jan 24 2013
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
25-Jan-2013 23:27, Nick Sabalausky пишет:
 On Thu, 24 Jan 2013 23:36:30 +0400
 Dmitry Olshansky <dmitry.olsh gmail.com> wrote:
 These days properties imply an action of, well, obtaining said value.
 If it's a wrapper as in "return zis variable" something is wrong
 already.

I agree in principle, but unfortunately "return zis variable" getters are often needed because no major language (that I know of) offers any other way to create data that's privately-writable and publicly-read-only - a very common need. Ie, that's the "something" that "is wrong already": the lack of a simple built-in "The public can only read this, but I can R/W it." to obviate an extremely common idiom.

It might be worth extending the access modifiers (not going to happen) or maybe simplifying the boilerplate... (could happen but dunno). -- Dmitry Olshansky
Jan 25 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 20:27, Nick Sabalausky wrote:

 I agree in principle, but unfortunately "return zis variable" getters
 are often needed because no major language (that I know of) offers any
 other way to create data that's privately-writable and
 publicly-read-only - a very common need.

 Ie, that's the "something" that "is wrong already": the lack of a
 simple built-in "The public can only read this, but I can R/W it." to
 obviate an extremely common idiom.

In Ruby one would do: class Foo attr_reader :foo end This would create a getter and an instance variable. Internally one can write directly do the instance variable, or create a setter: class Foo attr_reader :foo private def foo= (value) # code end end The equal sign indicates the method is a property. Not that "attr_reader" is not a language feature, it's implemented in the core library. There are also functions available for getter and both getter and setter. In D, I would like to see something like this: property(get, set) int a; property(get) int b; property(set) int c; property int d; // same as "a" This would create a getter and/or setter and an instance variable. One could also experiment with the protection attributes like this: public property(get, protected set) int a; One way could affect the instance variable, the other way to affect the getter/setter implementation. -- /Jacob Carlborg
Jan 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-26 19:55, Nick Sabalausky wrote:

 Interesting.

 Although with that in mind it seems my earlier statement is not
 entirely true. There are languages that offer a "publically read-only"
 feature: C# and Haxe. I think it just didn't occur to me because they
 do it via shorthand versions of their property syntaxes.

Depending on how you look at it, D1 with const variables does as well and Java with final variables. -- /Jacob Carlborg
Jan 26 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-23 19:08, Adam D. Ruppe wrote:

 My preferred solution is:

 1) all functions without  property work exactly the same way they do now
 (optional parenthesis, callable as setters with =)

 2) all functions with  property are ALWAYS rewritten so that a reference
 to them instead references the return value and/or the setter function.

 So the result would be similar to #define t.foo (t.foo()). The type
 system then takes care of the parenthesis - no special code is required
 for syntax.

What about functions not marked with property? writeln = "asd"; Doesn't look very nice. -- /Jacob Carlborg
Jan 23 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 5:46 PM, Adam D. Ruppe wrote:
 On Wednesday, 23 January 2013 at 22:24:20 UTC, Nick Sabalausky wrote:
 that provides absolutely no useful value whatsoever.

Do you think so many of us would be arguing for it and using it if it was of no value whatsoever?
 Note that properties are *not* functions

Indeed, which is why I separate out -property, a stupid waste of time, and property, a good idea. Parenthesis and properties have nothing to do with each other. But when property was proposed, we didn't talk about what it *is* (indistinguishable semantics from the return value), but instead what it *looks like* (must not be called with parenthesis). That's where all this pain comes from. Two separate features got intertwined due to a sloppy DIP.

We need a good DIP on this. UFCS has destroyed all arguments in favor of requiring parens. There is no question we must do this. Anyone inclined toward writing a detailed DIP? Andrei
Jan 23 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 8:59 PM, Nick Sabalausky wrote:
 On Wed, 23 Jan 2013 18:39:49 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:
 We need a good DIP on this. UFCS has destroyed all arguments in favor
 of requiring parens.

Uhh, how exactly?

With compelling examples that look awesome without parens and look awful with. Andrei
Jan 23 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 1:18 AM, monarch_dodra wrote:
 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:
 We need a good DIP on this. UFCS has destroyed all arguments in favor
 of requiring parens. There is no question we must do this. Anyone
 inclined toward writing a detailed DIP?

 Andrei

What about optional parens on non-UFCS calls, is there a case for this? Honest question.

Let them be.
 I'm inclined to writing a DIP.

That would be great! Andrei
Jan 23 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 4:28 AM, monarch_dodra wrote:
 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21

Walter convinced me last night that eliminating property is more sensible. Andrei
Jan 24 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 2:26 PM, Jonathan M Davis wrote:
 On Thursday, January 24, 2013 11:30:46 Andrei Alexandrescu wrote:
 On 1/24/13 4:28 AM, monarch_dodra wrote:
 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21

Walter convinced me last night that eliminating property is more sensible.

Well, that's bad news. It's bad enough that property hasn't been properly sorted out, but getting rid of it completely disregards the problems that it's trying to solve. Getting rid of property would be a horrible move IMHO.

No, the idea is to use better inference for the cases in which property would be appropriate. So we are looking at _changing_ the language, not simply ignoring property. Andrei
Jan 24 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 03:17, Brad Anderson wrote:
 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:
 We need a good DIP on this. [snip]

DIPs are good in theory but I think the process really needs to be formalized. In the past 3 years there have been thirteen DIPs with only one being approved and implemented.

According to this there's been four implemented: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs It think it seems correctly. -- /Jacob Carlborg
Jan 24 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 9:25 AM, deadalnix wrote:
 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:
 We need a good DIP on this. UFCS has destroyed all arguments in favor
 of requiring parens. There is no question we must do this. Anyone
 inclined toward writing a detailed DIP?

Let me strongly disagree. Language feature should never be introduced where library solution is possible.

Absolutes are difficult positions in language design.
 And library solution is possible. And opDispatch makes it possible.

Problem is, a lot of code would need to add opDispatch. I don't think that's good language design. Andrei
Jan 24 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-23 19:18, Johannes Pfau wrote:

 It might be an extreme corner case, but it's inconsistent behavior and
 confusing. Need a real-world example?
 http://www.digitalmars.com/d/archives/digitalmars/D/ModuleInfo.unitTest_cannot_be_called_twice_183357.html
 (with proper  property the first example should work as expected).

Yeah, that was kind of embarrassing. -- /Jacob Carlborg
Jan 23 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-23 19:48, Nick Sabalausky wrote:

 Having the *caller* decide whether something is a property or not makes
 as much sense as having the caller decide the function's name,
 signature and semantics.

In Ruby parentheses are optional when calling a method. I have never had any problem with that, although in Ruby you invoke a callable object with ".call". Property setters are more explicit in Ruby than D: def foo= (value) end The equal sign is actually part of the method name. -- /Jacob Carlborg
Jan 23 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/23/2013 11:46 PM, Nick Sabalausky wrote:
 On Wed, 23 Jan 2013 21:29:14 +0100
 Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 1/23/13, Adam D. Ruppe <destructionator gmail.com> wrote:
 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.

About property problems, I've recently ran into this: ModuleInfo.unitTest is defined as property void function() unitTest() nothrow pure; And if I use it: foreach (m; ModuleInfo) { if (m is null) continue; if (auto fp = m.unitTest) { fp(); // calls it m.unitTest(); // doesn't call it m.unitTest()(); // calls it } } This is regardless of the -property switch. I would expect the second call to work. Anyone know if this is filed already?

Don't know if it's filed, but yea: Optional empty-parens and the practice of conflating properties with functions is riddled with corner-cases. We can either try to patch over these corner cases with increasingly detailed new rules,

What are those "new" rules? The rules we already have are sufficient. Now the compiler needs to implement them properly.
 as Andrei is proposing, or we
 can just accept "the writing on the wall" (if you'll pardon my 80's-ism)
 that properties != functions.

That is not even the point of this discussion. a.map!(a=>foo(a,b).map!(a=>2*a)())().days().ago().writeln()
Jan 23 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 10:02 PM, Nick Sabalausky wrote:
 First of all, spacing helps:

 a.map!( a =>  foo(a,b).map!(a=>2*a)() )().days().ago().writeln()

 So does not trying to cram everything into a one-liner:

 auto descriptiveName = a =>  foo(a,b).map!(a=>2*a)();
 a.map!descriptiveName().days().ago().writeln()

 And then there's a few () in there, but not only do I fail to see how
 those hurt anybody, they make perfect sense since "days", "ago" and
 "writeln" are not data access, they're actions (even if maybe a little
 too cutely-named in the case of "ago").

If you find this not wanting and not improvable we might have reached an irreducible position. Andrei
Jan 23 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 04:02 AM, Nick Sabalausky wrote:
 On Thu, 24 Jan 2013 00:45:02 +0100
 Timon Gehr <timon.gehr gmx.ch> wrote:

 On 01/23/2013 11:46 PM, Nick Sabalausky wrote:
 On Wed, 23 Jan 2013 21:29:14 +0100
 ...
 Don't know if it's filed, but yea: Optional empty-parens and
 the practice of conflating properties with functions is riddled with
 corner-cases. We can either try to patch over these corner cases
 with increasingly detailed new rules,

What are those "new" rules? The rules we already have are sufficient. Now the compiler needs to implement them properly.

Andrei was just suggesting this: http://forum.dlang.org/post/kdpg5n$2qt2$1 digitalmars.com

This rule is not new. Also, it is about property.
 as Andrei is proposing, or we
 can just accept "the writing on the wall" (if you'll pardon my
 80's-ism) that properties != functions.

That is not even the point of this discussion. a.map!(a=>foo(a,b).map!(a=>2*a)())().days().ago().writeln()

First of all, spacing helps:

I do not see that. It just blows up the code even more.
 a.map!( a => foo(a,b).map!(a=>2*a)() )().days().ago().writeln()

 So does not trying to cram everything into a one-liner:

 auto descriptiveName = a => foo(a,b).map!(a=>2*a)();
 a.map!descriptiveName().days().ago().writeln()

This is not valid code.
 And then there's a few () in there, but not only do I fail to see how
 those hurt anybody, they make perfect sense since "days", "ago" and
 "writeln" are not data access, they're actions (even if maybe a little
 too cutely-named in the case of "ago").

There is no universal rule that says () has any relevance for this. (Arguably, it does not make any sense to distinguish concepts like 'data access' and 'action' syntactically. What is this distinction anyway?)
 (Of course, I'd question the meaningfulness and feasability of passing
 the "days" type constructor a range instead of a scalar, but I get that
 that's beside the point ;) )

No, that is spot on. I didn't even notice, which is partly owed to the paren spam.
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
 That is completely nonsensical behaviour. Just ignore -property.

Amen! -property MUST die. property should fix the real problems with properties, not leave that broken while adding new problems.
Jan 23 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:
 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
That is completely nonsensical behaviour. Just ignore -property.

Amen! -property MUST die. property should fix the real problems with properties, not leave that broken while adding new problems.

I'm starting to think that perhaps property should be disposed of completely. Just unify properties with nullary functions and be done with it. There is no semantic difference between them anyway. (Didn't D1 used to do that?) Compiling with -property also makes *compile-time* unary functions look ridiculous: int ctfeFunc(int arg)() { return dotDotDotMagic(arg); } void main() { //int x = ctfeFunc!(123); // doesn't work with -property! int x = ctfeFunc!(123)(); // looks ridiculous } T -- They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill
Jan 23 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, January 23, 2013 18:03:19 monarch_dodra wrote:
 So I thought I'd discuss: Would there be a reason to not make dur
 a property? This should impact no-one, but make ufcs usage that
 much more convenient. Can I get the go-ahead to make and document
 the change?

No. It's not conceptually a property, so it shouldn't be marked with property. It's a factory function.
 What about making things like msecs public aliases? How do you
 feel about that?

We have aliases already. If you don't like dur!"msecs"(100), you can do msecs(100). The same with days, minutes, etc. - Jonathan M Davis
Jan 23 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 17:47:44 UTC, H. S. Teoh wrote:
 I'm starting to think that perhaps  property should be disposed 
 of completely.

There is a problem property can potentially solve: a property returning a callable. alias void delegate() Callable; struct test { property Callable foo() { ... } } test t; Callable c = t.foo; // should work t.foo(); // should call the returned function t.foo()(); // this should NOT work Currently, t.foo()() DOES work and t.foo() gives the callable, without actually calling it (i.e. does not work as it should). -property and the current property implementation do not even try to address this. My preferred solution is: 1) all functions without property work exactly the same way they do now (optional parenthesis, callable as setters with =) 2) all functions with property are ALWAYS rewritten so that a reference to them instead references the return value and/or the setter function. So the result would be similar to #define t.foo (t.foo()). The type system then takes care of the parenthesis - no special code is required for syntax.
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 18:03:19 +0100
"monarch_dodra" <monarchdodra gmail.com> wrote:

 I was using dur, and as powerful as it is, I *hate* typing:
 
 //----
 Thread.sleep(dur!"msecs"(100));
 //----
 

I completely agree. It's absolutely hideous. And the flexibility of having the unit be a template param is only rarely useful. What we *do* fortunately have is these: msecs(100) hours(12) days(30) etc... But beyond that, unfortunately, it's all been discussed before, and the guy in charge of std.datetime is very strongly opposed to such changes and feels that 'dur!"msecs"(100)' is great-looking. It was a ridiculous uphill battle just to get the aliases above approved and included, and even then the phobos devs rejected the portions of the pull request that cleaned up phobos's internal usages of "durrrr" with the vastly cleaner aliases. Such code cleanup was deemed to be pointless and something to be avoided.
 
 Well, if you are compiling with "-property", the compiler forces 
 you to type:
 //----
 Thread.sleep(100.msecs());
 //----
 
 It is *almost* the same thing, but actually not the same at all. 
 It shatters the "native" feeling of the suffix notation.

The behavior *without* -property turned out to be a broken idea and the *with* -property was created as the new replacement, intended to deprecate the old ultimately-flawed behavior. Although that was a long time ago and there seems to be a lot of reluctance to finally make the switch because even the admins who admitted the change was necessary are big fans of the old behavior. Apparently, there's some fear about breaking code by making -propery the default *as was always intended*. But that potential breakage was the whole damn reason for adding the switch in the first place, as a transitional measure (which has now become what, about a two year "transition"?). Nevermind that we've had bigger breakages since then that didn't even have any transition period, and we got by just fine.
Jan 23 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 23 Jan 2013 09:45:49 -0800
schrieb "H. S. Teoh" <hsteoh quickfur.ath.cx>:

 On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:
 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
That is completely nonsensical behaviour. Just ignore -property.

Amen! -property MUST die. property should fix the real problems with properties, not leave that broken while adding new problems.

I'm starting to think that perhaps property should be disposed of completely.

Please do not forget the main reason for property: Returning a delegate from a function can become ambiguous without it: int a(){return 42;} void b() {return &a;} auto var = b; //OK auto var2 = b(); //is var2 == b or == 42? It might be an extreme corner case, but it's inconsistent behavior and confusing. Need a real-world example? http://www.digitalmars.com/d/archives/digitalmars/D/ModuleInfo.unitTest_cannot_be_called_twice_183357.html (with proper property the first example should work as expected). So if most people really think property is such a problem we can probably remove it, but we have to make sure examples like this one are not ambiguous.
Jan 23 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 23 Jan 2013 19:08:09 +0100
schrieb "Adam D. Ruppe" <destructionator gmail.com>:

 
 My preferred solution is:
 
 1) all functions without  property work exactly the same way they 
 do now (optional parenthesis, callable as setters with =)
 
 2) all functions with  property are ALWAYS rewritten so that a 
 reference to them instead references the return value and/or the 
 setter function.

This sounds OK, but you can still run into the callable issue if a normal function returns a callable. Probably add a rule that if a normal function returns a callable, calling it without parentheses is illegal.
Jan 23 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau 
wrote:
 This sounds OK, but you can still run into the callable issue 
 if a normal function returns a callable.

I don't think so because delegates require the parens to call anyway, and so do opCall objects (without the parens, it is just a reference to it).
 Probably add a rule that if a normal function returns a 
 callable, calling it without parentheses is illegal.

That's not a bad idea.
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 09:45:49 -0800
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:
 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
That is completely nonsensical behaviour. Just ignore -property.

Amen! -property MUST die. property should fix the real problems with properties, not leave that broken while adding new problems.

I'm starting to think that perhaps property should be disposed of completely. Just unify properties with nullary functions and be done with it. There is no semantic difference between them anyway. (Didn't D1 used to do that?)

Unfortunately, yea, D1 did do that. One of the many things that were fixed in D2 (at least it was partially fixed anyway). Having the *caller* decide whether something is a property or not makes as much sense as having the caller decide the function's name, signature and semantics. This level of need to go doing s/()/ over everything is blown ridiculously out of proportion. Not to mention misguided. I've dealt with code that consistently took advantage of D1's misfeature of disguising function calls as no-op statements, and it absolutely is a non-feature that provides no *real* benefit outside of code obfuscation contests. Properties are for *properties*, not for hacking around a language's syntax for the sake of a highly questionable and semantically misleading aesthetic "benefit". And just because certain people are unable/unwilling to see that there *is* in fact a meaningful distinction between "property" and "function" doesn't mean it isn't actually there.
 int x = ctfeFunc!(123)();	// looks ridiculous

If anything, that's an issue with template syntax, it has nothing to do with properties, let alone the beloved practice of abusing properties for the sake of things that clearly are not properties.
Jan 23 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 23 January 2013 at 18:02:05 UTC, Jonathan M Davis 
wrote:
 We have aliases already. If you don't like dur!"msecs"(100), 
 you can do
 msecs(100). The same with days, minutes, etc.

 - Jonathan M Davis

Hum. I guess I missed those. Thanks.
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 19:40:02 +0100
"Adam D. Ruppe" <destructionator gmail.com> wrote:

 On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau 
 wrote:
 This sounds OK, but you can still run into the callable issue 
 if a normal function returns a callable.

I don't think so because delegates require the parens to call anyway, and so do opCall objects (without the parens, it is just a reference to it).

So you want it to work like this?: void foo() {...} void delegate() {...} bar; foo; // call it bar; // don't call it Yuck. It's already bad enough that we have this goofy mess: int func() {...} void foo(int a) {...} void bar(int delegate() dg) {...} template baz(alias a) {...} foo(func); // Calls func bar(&func); // Doesn't call func, just refers to it baz!(func); // Doesn't call func, just refers to it baz!(&func); // Error WTF?
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 13:57:32 -0500
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:
     void delegate() {...} bar;

Erm, obviously I meant: void delegate() bar = ...;
Jan 23 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 18:57:38 UTC, Nick Sabalausky 
wrote:
 So you want it to work like this?:

Yes, keeping the current behavior unless you opt-in to property (though I wouldn't object to Dmitry's idea of "error: expression has no effect"). If I update dmd again and get 1,000 useless errors over a trivial syntax change because some people on the newsgroups are insisting on cleansing the unbelievers, it is just going to make me sad.
 It's already bad enough that we have this goofy mess:

meh, I don't have a problem with any of that.
Jan 23 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 23 Jan 2013 19:40:02 +0100
schrieb "Adam D. Ruppe" <destructionator gmail.com>:

 On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau 
 wrote:
 This sounds OK, but you can still run into the callable issue 
 if a normal function returns a callable.

I don't think so because delegates require the parens to call anyway, and so do opCall objects (without the parens, it is just a reference to it).

Yes, the delegate needs the parentheses but the function does not: int DG() {return 42}; int delegate() getDG() {return &DG}; auto dg = getDG; //OK auto ??? = getDG(); The last line could be a call to getDG with optional parenthesis, so ??? = DG. Or it could be a call to getDG without optional parenthesis and a call to the returned DG, so ??? = 42.
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 23:03:32 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 23-Jan-2013 22:57, Nick Sabalausky =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 On Wed, 23 Jan 2013 19:40:02 +0100
 "Adam D. Ruppe" <destructionator gmail.com> wrote:

 On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau
 wrote:
 This sounds OK, but you can still run into the callable issue
 if a normal function returns a callable.

I don't think so because delegates require the parens to call anyway, and so do opCall objects (without the parens, it is just a reference to it).

So you want it to work like this?: void foo() {...} void delegate() {...} bar; foo; // call it

This is a call, arguably bad style =20
      bar; // don't call it

compile-time error, as statement has no side-effects? (and we have this kind of check even now) =20 =20 =20

int foo() {...} int delegate() {...} bar; auto x =3D foo; // call it auto y =3D bar; // don't call it
Jan 23 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 19:18:09 UTC, Johannes Pfau 
wrote:
 int DG() {return 42};
 int delegate() getDG() {return &DG};

 auto dg = getDG; //OK
 auto ??? = getDG();

 The last line could be a call to getDG with optional 
 parenthesis,
 so ??? = DG. Or it could be a call to getDG without optional
 parenthesis and a call to the returned DG, so ??? = 42.

If getDG is a property, ??? == 42, because getDG() is rewritten into (getDG())() - parens there would ALWAYS mean "call the return value", so any property is indistinguishable from its return value. (if we get property like I want) Without property, it'd return DG because while parenthesis are optional, if they are present, they always apply to the preceding thing directly; getDG == getDG() in all cases. (This is the status quo, which I'd retain) The type system will help catch errors here better than the syntax.
Jan 23 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 19:29:44 UTC, Nick Sabalausky 
wrote:
 int foo() {...}
 int delegate() {...} bar;

 auto x = foo; // call it
 auto y = bar; // don't call it

I don't have a problem with that because delegates and functions are different beasts anyway. For one major example, you can't rebind a function, but you can rebind a delegate, so "bar" has a meaning that "foo" doesn't (and &bar and &foo are different beasts too, one is address of a (rebindable) pointer, the other is address of a function, so they won't match up either).
Jan 23 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 23 January 2013 at 18:02:05 UTC, Jonathan M Davis 
wrote:
 On Wednesday, January 23, 2013 18:03:19 monarch_dodra wrote:
 So I thought I'd discuss: Would there be a reason to not make 
 dur
 a property? This should impact no-one, but make ufcs usage that
 much more convenient. Can I get the go-ahead to make and 
 document
 the change?

No. It's not conceptually a property, so it shouldn't be marked with property. It's a factory function.

I agree. It's important we don't conflate properties with parentheses-less calling. They are two separate things. I want to be able to call without parentheses but we shouldn't abuse property to accomplish it. BA
Jan 23 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/23/13, Adam D. Ruppe <destructionator gmail.com> wrote:
 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.

About property problems, I've recently ran into this: ModuleInfo.unitTest is defined as property void function() unitTest() nothrow pure; And if I use it: foreach (m; ModuleInfo) { if (m is null) continue; if (auto fp = m.unitTest) { fp(); // calls it m.unitTest(); // doesn't call it m.unitTest()(); // calls it } } This is regardless of the -property switch. I would expect the second call to work. Anyone know if this is filed already?
Jan 23 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-23 18:03, monarch_dodra wrote:
 I was using dur, and as powerful as it is, I *hate* typing:

 //----
 Thread.sleep(dur!"msecs"(100));
 //----

 Then, this reminded me of an older thread I started:
 Neat: UFCS for integer dot operator suffix
 http://forum.dlang.org/thread/uchcycnsvykuojzhuokh forum.dlang.org

 And then it struct me:
 //----
 Thread.sleep(100.dur!"msecs");
 //----

 Yay! Or even better:
 //----
 alias msecs = dur!"msecs"
 ...
 Thread.sleep(100.msecs); //Wow. Talk about expressive !!!

This is how it should look like. Date ranges in Ruby on Rails can be really beautiful: date = 2.days.ago I think we should have the same in D.
 What about making things like msecs public aliases? How do you feel
 about that?

Go for it. -- /Jacob Carlborg
Jan 23 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-23 21:46, Jonathan M Davis wrote:

 I confess that it's syntax like that that makes dislike UFCS. I can see why
 you might like it, but personally, I find it to be hideous.

 But as long as you're not using -property, you can do 2.days to get a Duration
 of 2 days, much as I wish that you couldn't.

The point is that the code should read like regular text. But if you do: auto t = ago(days(2)); It's backwards but it's still better than: auto a = Time.now() - 60 * 60 * 24 * 2; // don't know the exact syntax -- /Jacob Carlborg
Jan 23 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/23/2013 10:08 PM, Jonathan M Davis wrote:
 On Wednesday, January 23, 2013 21:54:54 Jacob Carlborg wrote:
 On 2013-01-23 21:46, Jonathan M Davis wrote:
 I confess that it's syntax like that that makes dislike UFCS. I can see
 why
 you might like it, but personally, I find it to be hideous.

 But as long as you're not using -property, you can do 2.days to get a
 Duration of 2 days, much as I wish that you couldn't.

The point is that the code should read like regular text.

I know that that's what you're going for, but I don't agree with it at all. It's code, not a novel.

What is the point?
 But if you do:

 auto t = ago(days(2));

 It's backwards

I've programmed enough in functional languages (and in a functional style in non-functional languages) to find 2.days().ago() to be horribly backwards.

IMHO, this is ridiculous. Real Haskell programmers are flexible enough to use both orders. sun^.position.x
 but it's still better than:

 auto a = Time.now() - 60 * 60 * 24 * 2; // don't know the exact syntax

Well, of course that's horrible. It's using naked numbers. The correct syntax would be auto a = Clock.currTime() - dur!"days"(2); or if you don't want to use dur auto a = Clock.currTime() - days(2); And I see no problem with that. - Jonathan M Davis

Likewise, there is no problem with 2.days.ago. Clock.currTime() - dur!"days"(2) is more verbose without being more clear.
Jan 23 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/23/2013 10:59 PM, monarch_dodra wrote:
 ...
 --------
 IMO: We should be able to keep the optional parenthesis for all
 functions (except maybe those that return delegates). Things that are
 marked as property, however, MUST respect two things:
 1) properties should *NEVER* have parentheses.
 2) you should not be able to take the address of a property function.
 3) The "a.prop = value" should call "a.prop(value)" IFF prop is declared
 property.

 This (I think), should make everyone happy. Callers can still choose
 their own styles, especially in the context of UFCS.

 As for  property: this makes it able to guarantee what it was originally
 designed for.

 ...

 Or am I completely wrong? Did I miss anything?

1 and 2 are necessary. I do not care about 3. IIRC Adam likes to have both fun = value and fun(value) available for the same function.
Jan 23 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 06:16, Nick Sabalausky wrote:

 Heh, actually, case in point, take a look at my normal work setup:

 http://66.228.38.161/download/img/jobs-would-have-hung-employees-for-doing-this.jpg

 (Yes, I need to get a wireless keyboard/trackball ;) )

That's not a good work setup, in any way. Close the laptop and get a real, external monitor, or two. I'm serious, you're going to break your neck, sooner or later.
 Now, for  property setters, we might use them for other
 operations too.

  property int a() { return 10; }
  property void a(int v) { ... }

 a += 10;

 should be transformed into a(a() + 10); which is not currently
 done.

Geez, we still don't have that?

No we don't :( That's also one reason why a public fields cannot be changed to a property without breaking the API, see: http://forum.dlang.org/thread/ceukykobasewoexsrveb forum.dlang.org?page=8#post-kdqs3u:2414i1:241:40digitalmars.com -- /Jacob Carlborg
Jan 24 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-23 22:59, monarch_dodra wrote:

 In this context, what does it mean then to have something be "a property" ?

 I think we should remember what " property" (as I understood it) is
 meant for: a function that can emulate being a object. The de-facto
 example being "front".

It's for a method emulating being a field/public instance variable.
 The "final" objective (as I understood it), is that you can publish your
 interface, and later, swap object/members for functions (and vice versa).

You cannot do this in D. There are at least two issues: 1. You cannot replace a non-final property, i.e. a method, with a field. Someone might have overridden the method in a subclass. In other languages like Scala a public instance variable is implemented as a method. In these cases you can switch freely between a property and an instance variable. 2. There are some issues with fields of a struct type being changed to a property, since they are usually passed by value. Example: struct Bar { int a; } class Foo { Bar bar; } void main () { auto foo = new Foo; foo.bar.a = 1; assert(foo.bar.a == 1); } Changing Foo.bar to be a porperty like this: class Foo { Bar bar_; property Bar bar () { return bar_; } property Bar bar (Bar bar) { return bar_ = bar; } } Now the assertion in main won't pass since the property is returning a value type that is copied. If you instead return by reference it will work, but then you can also set "bar" directly, bypassing the setter. For this to work properly we would need property rewrite: foo.bar.a = 1; Should be turned into: auto _tmp = foo.bar(); _tmp.a = 1; foo.bar(_tmp); -- /Jacob Carlborg
Jan 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 10:11, monarch_dodra wrote:

 IMO, it not currently doing so is a limitation

Yes, that's what I'm saying. You cannot swap properties and fields willy nilly using the current implementation. -- /Jacob Carlborg
Jan 24 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 00:16, Nick Sabalausky wrote:

 I'll certainly grant that, insofar as the written order is backwards
 from the execution order. I think the "ago" is that part that bugs me
 the most. It's too clever. I could live with "2.days", but I'd prefer
 "days(2)" since that looks like a type constructor, and "days" isn't a
 property of 2. Maybe "2.toDays()", but at that point I'd still rather
 just do the simpler "days(2)".

If you don't have "ago" how would you determine the differences compared to the opposite, which looks like this in Ruby on Rails: time = 2.days.from_now "2" is the duration, "days" is the unit and ago/from_now indicates if it's positive or negative. -- /Jacob Carlborg
Jan 24 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 10:52 AM, Nick Sabalausky wrote:
 now - blah vs. now + blah

Now we have caught you.
Jan 24 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 3:38 AM, Tommi wrote:
 I've always secretly hated the ambiguity in D's syntax. E.g:

 foo.bar

 What could foo and bar be? D has many more answers than C++:

 D C++
 foo bar foo bar
 Module/Namespace x x
 Type x x
 Variable x x x x
 Method x
 Free function x x

Nah, C++ has also namespace, inner classes and function-local classes... lookup and resolution are actually more complicated than D. Andrei
Jan 24 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 11:32 AM, deadalnix wrote:
 On Thursday, 24 January 2013 at 16:27:02 UTC, Andrei Alexandrescu wrote:
 On 1/24/13 3:38 AM, Tommi wrote:
 I've always secretly hated the ambiguity in D's syntax. E.g:

 foo.bar

 What could foo and bar be? D has many more answers than C++:

 D C++
 foo bar foo bar
 Module/Namespace x x
 Type x x
 Variable x x x x
 Method x
 Free function x x

Nah, C++ has also namespace, inner classes and function-local classes... lookup and resolution are actually more complicated than D.

No. C++ has no forward references, no UFCS, and no way to introduce new symbols during semantic analysis. C++ is an horrible beast, but on the identifier side, D is far worse.

Well if D is worse, should we give up on forward references, UFCS, or mixins? Andrei
Jan 24 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 07:12 PM, Andrei Alexandrescu wrote:
 On 1/24/13 11:32 AM, deadalnix wrote:
 On Thursday, 24 January 2013 at 16:27:02 UTC, Andrei Alexandrescu wrote:
 On 1/24/13 3:38 AM, Tommi wrote:
 I've always secretly hated the ambiguity in D's syntax. E.g:

 foo.bar

 What could foo and bar be? D has many more answers than C++:

 D C++
 foo bar foo bar
 Module/Namespace x x
 Type x x
 Variable x x x x
 Method x
 Free function x x

Nah, C++ has also namespace, inner classes and function-local classes... lookup and resolution are actually more complicated than D.

No. C++ has no forward references, no UFCS, and no way to introduce new symbols during semantic analysis. C++ is an horrible beast, but on the identifier side, D is far worse.

Well if D is worse, should we give up on forward references, UFCS, or mixins? Andrei

Also, static if and 'is' expressions. No, but we must specify and implement a sophisticated evaluation model of compile-time code evaluation, introspection, and generation constructs. DMD gets it wrong. Semantics of code, or whether it is accepted may depend on the order modules are passed on the command line. I'll release what I have got so far later in spring.
Jan 24 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 17:27, Andrei Alexandrescu wrote:

 Nah, C++ has also namespace, inner classes and function-local classes...
 lookup and resolution are actually more complicated than D.

A namespace in C++ would be using a double colon, not a dot. -- /Jacob Carlborg
Jan 24 2013
prev sibling next sibling parent Mike Wey <mike-wey example.com> writes:
On 01/23/2013 09:33 PM, Jacob Carlborg wrote:
 This is how it should look like. Date ranges in Ruby on Rails can be
 really beautiful:

 date = 2.days.ago

 I think we should have the same in D.

As long as your not using -property: http://dpaste.dzfl.pl/56960911 -- Mike Wey
Jan 23 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 00:07, Nick Sabalausky wrote:

 Honestly, I really don't like that. It trades clear semantics for a
 bunch of magic to achieve the dubious goal of making code look more
 like English (a notably high-ambiguity language). If I valued languages
 imitating English, I'd be doing everything in HyperCard or COBOL or
 some other such design blunder.

That's unclear with the semantics? -- /Jacob Carlborg
Jan 24 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
24-Jan-2013 12:53, Jacob Carlborg пишет:
 On 2013-01-24 00:07, Nick Sabalausky wrote:

 Honestly, I really don't like that. It trades clear semantics for a
 bunch of magic to achieve the dubious goal of making code look more
 like English (a notably high-ambiguity language). If I valued languages
 imitating English, I'd be doing everything in HyperCard or COBOL or
 some other such design blunder.

That's unclear with the semantics?

+1 It's crystal clear, and the less noise the better IMO. -- Dmitry Olshansky
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, January 23, 2013 21:33:07 Jacob Carlborg wrote:
 This is how it should look like. Date ranges in Ruby on Rails can be
 really beautiful:
 
 date = 2.days.ago
 
 I think we should have the same in D.

I confess that it's syntax like that that makes dislike UFCS. I can see why you might like it, but personally, I find it to be hideous. But as long as you're not using -property, you can do 2.days to get a Duration of 2 days, much as I wish that you couldn't. - Jonathan M Davis
Jan 23 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 20:37:23 UTC, Jacob Carlborg 
wrote:
 What about functions not marked with  property?

 writeln = "asd";

 Doesn't look very nice.

struct FileNotFound { int payload; FileNotFound opBinary(string op : "+")(FileNotFound rhs) { return this.payload * rhs.payload; } } /* LOL INDENTATION */ FileNotFound descriptiveVariableNamesArentMyThingLOLOLOLOL; descriptiveVariableNamesArentMyThingLOLOLOLOL.payload = 20; auto rofl = descriptiveVariableNamesArentMyThingLOLOLOLOL + FileNotFound(100); // LOLOLOLOL rofl.payload == 2000!!!!!!!!!!!!!!!! All of that looks pretty terrible too, from the awful names, the broken indentation, the useless comment, and of course, the + operator being overloaded to mean multiplication too. But that's no reason to for the compiler to reject operator overloading, comments, or long variable names, because these things are useful, when not abused by a deranged lunatic. Simlarly, writeln = 10 might not look very nice, but className = "foo" does.... and it is the same feature, used in real world D code now (that would break if we changed it).
Jan 23 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, January 23, 2013 21:54:54 Jacob Carlborg wrote:
 On 2013-01-23 21:46, Jonathan M Davis wrote:
 I confess that it's syntax like that that makes dislike UFCS. I can see
 why
 you might like it, but personally, I find it to be hideous.
 
 But as long as you're not using -property, you can do 2.days to get a
 Duration of 2 days, much as I wish that you couldn't.

The point is that the code should read like regular text.

I know that that's what you're going for, but I don't agree with it at all. It's code, not a novel.
 But if you do:
 
 auto t = ago(days(2));
 
 It's backwards

I've programmed enough in functional languages (and in a functional style in non-functional languages) to find 2.days().ago() to be horribly backwards.
 but it's still better than:
 
 auto a = Time.now() - 60 * 60 * 24 * 2; // don't know the exact syntax

Well, of course that's horrible. It's using naked numbers. The correct syntax would be auto a = Clock.currTime() - dur!"days"(2); or if you don't want to use dur auto a = Clock.currTime() - days(2); And I see no problem with that. - Jonathan M Davis
Jan 23 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
OK. I'm going to try to shift the object of this discussion. 
Let's forget style for a little (I loves me both the functional 
notation, but am also a syntax Nazi).

Clearly, not everyone agrees with what constitutes a property, 
and what doesn't. Because of this, there is a strong urge to make 
parenthesis *on functions* optional (especially when UFCS gets 
mixed in).

In this context, what does it mean then to have something be "a 
property" ?

I think we should remember what " property" (as I understood it) 
is meant for: a function that can emulate being a object. The 
de-facto example being "front".

The "final" objective (as I understood it), is that you can 
publish your interface, and later, swap object/members for 
functions (and vice versa).

When you think about it: The (no) parentheses is really just a 
side effect of being a property, but not the root objective. As 
for enforcing parenthesis on non-property: Well, that has nothing 
to do with  property, when you think of it

--------
IMO: We should be able to keep the optional parenthesis for all 
functions (except maybe those that return delegates). Things that 
are marked as property, however, MUST respect two things:
1) properties should *NEVER* have parentheses.
2) you should not be able to take the address of a property 
function.
3) The "a.prop = value" should call "a.prop(value)" IFF prop is 
declared property.

This (I think), should make everyone happy. Callers can still 
choose their own styles, especially in the context of UFCS.

As for  property: this makes it able to guarantee what it was 
originally designed for.

...

Or am I completely wrong? Did I miss anything?
Jan 23 2013
prev sibling next sibling parent "anonymous" <anonymous example.com> writes:
My two cents on properties (comments along the way):

alias int delegate() C;
C c;
auto noprop() {return c;}
void noprop(C v) {c = v;}
 property auto prop() {return c;}
 property void prop(C v) {c = v;}

static assert(
    is(typeof( noprop             ) == function) /* well ... I 
guess, technically */
&& is(typeof( prop               ) == C) /* ok */

&& is(typeof( {return noprop;}() ) == C) /* fails with -property. 
that's goofy */
&& is(typeof( {return prop;}()   ) == C) /* ok */

&& is(typeof( {noprop = c;}      )) /* fails with -property. 
that's alright */
&& is(typeof( {prop = c;}        )) /* ok */

&& is(typeof( &noprop            ) == C function()) /* of course 
*/
&& is(typeof( &prop              ) == C function()  property) /* 
bad, should be typeof(&c) */

&& is(typeof( noprop()           ) == C) /* of course */
&& is(typeof( prop()             ) == C) /* bad, should be int */

&& is(typeof( noprop()()         ) == int) /* of course */
&& is(typeof( prop()()           ) == int) /* bad, should error */
);
Jan 23 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 22:07:30 UTC, Timon Gehr wrote:
 IIRC Adam likes to have both fun = value and fun(value) 
 available for the same function.

Yeah, it is sometimes useful for methods that can be both chained and assigned: foo.bar(10).baz("hello"); vs foo.bar = 10; foo.baz = "hello"; ...and sometimes just as a quick convenience when hunting bugs (yup, I'm kinda for writeln = str; because you can throw that in without hunting for the end of the expression to put in the close paren. I see no reason to change the current behavior for non- property. Now, for property setters, we might use them for other operations too. property int a() { return 10; } property void a(int v) { ... } a += 10; should be transformed into a(a() + 10); which is not currently done.
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 21:48:32 +0100
"Adam D. Ruppe" <destructionator gmail.com> wrote:

 On Wednesday, 23 January 2013 at 20:37:23 UTC, Jacob Carlborg 
 wrote:
 What about functions not marked with  property?

 writeln = "asd";

 Doesn't look very nice.

struct FileNotFound { int payload; FileNotFound opBinary(string op : "+")(FileNotFound rhs) { return this.payload * rhs.payload; } } /* LOL INDENTATION */ FileNotFound descriptiveVariableNamesArentMyThingLOLOLOLOL; descriptiveVariableNamesArentMyThingLOLOLOLOL.payload = 20; auto rofl = descriptiveVariableNamesArentMyThingLOLOLOLOL + FileNotFound(100); // LOLOLOLOL rofl.payload == 2000!!!!!!!!!!!!!!!! All of that looks pretty terrible too, from the awful names, the broken indentation, the useless comment, and of course, the + operator being overloaded to mean multiplication too. But that's no reason to for the compiler to reject operator overloading, comments, or long variable names, because these things are useful, when not abused by a deranged lunatic. Simlarly, writeln = 10 might not look very nice, but className = "foo" does.... and it is the same feature, used in real world D code now (that would break if we changed it).

1. Bad comparison because operator overloading, symbol names, etc are determined by the *callee*, not the caller. That is as it should be. 2. Strawman. The ability to write bad code is NOT valid justification for offering a feature (ie the ability to call *any* arbitrary single-arg function, rather than just properties, using assignment syntax) that provides absolutely no useful value whatsoever. Note that properties are *not* functions, they're only implemented using functions (though D's syntax unfortunately does its best to conflate the two notions - at least in part because those who originally designed property openly didn't understand and didn't like the whole concept of properties). Properties are fundamentally different from functions as they are used for a fundamentally different conceptual model (yes, sometimes there is a grey area - *SOMETIMES*, not usually). And this is a distinction that is *inherently* made by the *callee*. The caller doesn't have a damn thing to do with the choice other than to either get it right or get it wrong - so why *allow* them to get it wrong? What does that gain anyone? Not a damn thing. Overly long variable names are NOT an accurate comparison here because the border between good/bad variable names is impossibly fuzzy. Whereas this, OTOH is binary: Either the author designed it as a property or didn't. You can maybe argue with their choice in *some* cases, but bottom line, it's either a property or it isn't. The caller doesn't have jack shit to do with it. What you're suggesting is comparable to allowing the caller to determine member visibility. Or member existence, for that matter. Or capitalization (I hate case-insensitive languages - what the hell does that ability gain anybody other than helping to introduce inconsistency and sloppiness? It's a non-feature - ditch it.) (FWIW, I'm not advocating making dur a property. "minutes" is obviously not a property of 10.)
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 15:11:35 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/23/13 1:18 PM, Johannes Pfau wrote:
 Please do not forget the main reason for  property: Returning a
 delegate from a function can become ambiguous without it:

 int a(){return 42;}
 void b() {return&a;}

 auto var = b; //OK
 auto var2 = b(); //is var2 == b or == 42?

 It might be an extreme corner case, but it's inconsistent behavior
 and confusing.

Agreed. I think we should require property only for those cases, and not any others. Andrei

I'd rather not see more "Sometimes the language lets me skip XXXX, and sometimes it complains" get introduced into the language. That complicates the language and makes the language harder to understand. There are cases where that strategy has certainly made sense, but at this point I think you're just grasping for ways to justify leaving in the non-beneficial "Use either 'foo' or 'foo()', whichever you want, anytime you want" sloppiness. And making sure that non-feature can remain by introducing more special-cases into the language to patch over the problems with the non-feature.
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 15:14:21 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/23/13 1:48 PM, Nick Sabalausky wrote:
 Having the *caller* decide whether something is a property or not
 makes as much sense as having the caller decide the function's name,
 signature and semantics.

No. The caller does get to decide a variety of syntactic aspects of the invocation.

Yes, but it's unfortunate that includes a part of the syntax that carries semantic/conceptual implications for something (action or data) that is already *inherently* determined by writer of the *callee*.
 If anything, that's an issue with template syntax, it has nothing
 to do with properties, let alone the beloved practice of abusing
 properties for the sake of things that clearly are not properties.

The implied assumption here is that if it doesn't have parens it's a property. Well it's a function call.

Right, it's a function call. So what in the world do we gain by allowing the caller to make it look like something it isn't? Nothing.
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 21:29:14 +0100
Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 1/23/13, Adam D. Ruppe <destructionator gmail.com> wrote:
 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.

About property problems, I've recently ran into this: ModuleInfo.unitTest is defined as property void function() unitTest() nothrow pure; And if I use it: foreach (m; ModuleInfo) { if (m is null) continue; if (auto fp = m.unitTest) { fp(); // calls it m.unitTest(); // doesn't call it m.unitTest()(); // calls it } } This is regardless of the -property switch. I would expect the second call to work. Anyone know if this is filed already?

Don't know if it's filed, but yea: Optional empty-parens and the practice of conflating properties with functions is riddled with corner-cases. We can either try to patch over these corner cases with increasingly detailed new rules, as Andrei is proposing, or we can just accept "the writing on the wall" (if you'll pardon my 80's-ism) that properties != functions.
Jan 23 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 22:24:20 UTC, Nick Sabalausky 
wrote:
 that provides absolutely no useful value whatsoever.

Do you think so many of us would be arguing for it and using it if it was of no value whatsoever?
 Note that properties are *not* functions

Indeed, which is why I separate out -property, a stupid waste of time, and property, a good idea. Parenthesis and properties have nothing to do with each other. But when property was proposed, we didn't talk about what it *is* (indistinguishable semantics from the return value), but instead what it *looks like* (must not be called with parenthesis). That's where all this pain comes from. Two separate features got intertwined due to a sloppy DIP. You're talking about removing a feature (optional parenthesis) from the language. We need to be weary of doing that. You say it is useless... but it *is* used by many of us. Changing it now has a cost. Even if it was worthless, the benefit of killing a worthless feature is smaller than the harm caused by breaking the code. Similarly, I feel the new keyword is a detriment (indeed, I think new is less useful than optional parens). It doesn't do anything that can't be done in the library and gives special treatment to one preferred allocator (the gc), discouraging others and preventing easy replacement with user defined types (e.g. a create method that returns NotNull!T instead of T). But the fact is that new is a feature in D today, and removing it would break a heck of a lot of code, so if I was given a vote on removing it... I'd vote to keep it how it is. Now, property semantics are an entirely different issue, and thanks to the property decoration, we CAN fix them without breaking anything else. That's a no-brainer to me, we should definitely do that.
Jan 23 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 20:29:24 UTC, Andrej Mitrovic 
wrote:
 This is regardless of the -property switch. I would expect the 
 second call to work.

Indeed. I don't know if it is filed (I think I saw it mentioned on irc yesterday though, so it might be), but this is exactly why -property is so useless: it doesn't even solve the problem (exactly what you saw there!) that property was supposed to address! The current implementation ONLY checks syntax. That's completely backward: if we got the semantics right, the syntax of properties would take care of itself.
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 21:33:07 +0100
Jacob Carlborg <doob me.com> wrote:
 
 This is how it should look like. Date ranges in Ruby on Rails can be 
 really beautiful:
 
 date = 2.days.ago
 

Honestly, I really don't like that. It trades clear semantics for a bunch of magic to achieve the dubious goal of making code look more like English (a notably high-ambiguity language). If I valued languages imitating English, I'd be doing everything in HyperCard or COBOL or some other such design blunder.
Jan 23 2013
prev sibling next sibling parent "anonymous" <anonymous example.com> writes:
On Wednesday, 23 January 2013 at 22:07:20 UTC, anonymous wrote:
 alias int delegate() C;
 C c;
 auto noprop() {return c;}
 void noprop(C v) {c = v;}
  property auto prop() {return c;}
  property void prop(C v) {c = v;}

 && is(typeof( {return noprop;}() ) == C) /* fails with 
 -property. that's goofy */

non-properties. Just don't apply that rule to UFCS. Some more: static assert( is(typeof( noprop(c) )) /* of course */ && is(typeof( prop(c) )) /* should error */ ); void noprop(C, int); property void prop(C, int); static assert( is(typeof( {c.noprop;} )) /* fails with -property, should work, is explicit enough */ && is(typeof( {c.prop;} )) /* should error */ && is(typeof( {c.noprop();} )) /* ok */ && is(typeof( {c.prop();} )) /* should error */ && is(typeof( {c.noprop(0);} )) /* ok */ && is(typeof( {c.prop(0);} )) /* should error */ && is(typeof( {c.noprop = 0;} )) /* fails with -property, alright */ && is(typeof( {c.prop = 0;} )) /* ok */ );
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 21:54:54 +0100
Jacob Carlborg <doob me.com> wrote:

 On 2013-01-23 21:46, Jonathan M Davis wrote:
 
 I confess that it's syntax like that that makes dislike UFCS. I can
 see why you might like it, but personally, I find it to be hideous.

 But as long as you're not using -property, you can do 2.days to get
 a Duration of 2 days, much as I wish that you couldn't.

The point is that the code should read like regular text. But if you do: auto t = ago(days(2)); It's backwards[...]

I'll certainly grant that, insofar as the written order is backwards from the execution order. I think the "ago" is that part that bugs me the most. It's too clever. I could live with "2.days", but I'd prefer "days(2)" since that looks like a type constructor, and "days" isn't a property of 2. Maybe "2.toDays()", but at that point I'd still rather just do the simpler "days(2)".
Jan 23 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, January 23, 2013 18:35:24 Andrei Alexandrescu wrote:
 UFCS has effectively buried the case for requiring parens.

Honestly, I'd love to require parens even with UFCS, but I think that it's clear that most folks want the parens to be optional for UFCS, and at this point, requiring parens would break a lot of code. So, even if it were generally agreed upon that it's a great idea to require them, the cost in code breakage would risk making the change unacceptable. - Jonathan M Davis
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 18:39:49 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 
 We need a good DIP on this. UFCS has destroyed all arguments in favor
 of requiring parens.

Uhh, how exactly?
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 00:30:43 +0100
Timon Gehr <timon.gehr gmx.ch> wrote:

 On 01/23/2013 11:40 PM, Nick Sabalausky wrote:
 On Wed, 23 Jan 2013 15:14:21 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/23/13 1:48 PM, Nick Sabalausky wrote:
 Having the *caller* decide whether something is a property or not
 makes as much sense as having the caller decide the function's
 name, signature and semantics.

No. The caller does get to decide a variety of syntactic aspects of the invocation.

Yes, but it's unfortunate that includes a part of the syntax that carries semantic/conceptual implications for something (action or data) that is already *inherently* determined by writer of the *callee*.

Keeping or leaving out the parens has no semantic implications.

foo.bar() // Perform action foo.bar // Access data
Jan 23 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
Alexandrescu wrote:
 We need a good DIP on this. [snip]

DIPs are good in theory but I think the process really needs to be formalized. In the past 3 years there have been thirteen DIPs with only one being approved and implemented. Perhaps 12 of those really weren't good enough to pursue but, upon looking at some of the proposals I really like, I think it's probably more the case that they get proposed and then the community forgets about them. DIPs seem to be the place where good ideas go to die. I think just applying the phobos module review process to DIPs would help a lot (although that process suffers from a lack of initiative in actually running reviews but I think that's something that can be overcome). It'd force the community to make a yea or nay decision instead of just letting them languish in the wiki. BA
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 18:38:11 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/23/13 5:40 PM, Nick Sabalausky wrote:
 On Wed, 23 Jan 2013 15:14:21 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:

 On 1/23/13 1:48 PM, Nick Sabalausky wrote:
 Having the *caller* decide whether something is a property or not
 makes as much sense as having the caller decide the function's
 name, signature and semantics.

No. The caller does get to decide a variety of syntactic aspects of the invocation.

Yes, but it's unfortunate that includes a part of the syntax that carries semantic/conceptual implications for something (action or data) that is already *inherently* determined by writer of the *callee*.

"Semantic" and "conceptual" sound interesting but are a bit out of context here. We're talking simple syntax here, and in particular an option available to other languages already.

I realize that you think properties are purely a syntactic matter, but that misunderstanding is the heart of the problem. You're thinking "Do I feel like calling this function with or without parens?" That's completely wrong and demonstrates a continued misunderstanding of properties. The real question is "Is this an action or data?" (And obviously I mean when viewed from outside the encapsulation, I don't mean the implementation.) Note that the answer to that question is NOT subjective to the context of the caller, only the callee. Blindly discounting the "conceptual" matter (ie "action or data?") is a convenient way contort the issue so that it fits back into the "Call with/without parens?" strawman. There have already been enough problems shown that have arisen as a direct result of mistreating the matter of properties as merely an "optional paren" syntax matter. You suggest various additional rules to patch over those symptoms, but when you consider the very simple, time-honored, and frankly very very common, association of: foo.bar() // Perform action foo.bar // Read/Write data Then you'll notice that all those edge cases created by the "optional paren" mindset simply vanish as natural straightforward consequences of the above rule. No need for any additional rules or "sometimes required, sometimes optional" puzzles. This is a problem that other languages have *already* solved, with well-known, well-understood solutions (ie: the "action==paren, data==no parem" rule). Unfortunately, despite the readily available solution, D is still trying to wrap its head around the matter, and winds up flailing around in a sea of issues because it is (you are) desperately clinging to the failed (ie: it creates problems) and unimportant notion of "No matter what happens with properties, I *must* be able to decide on a whim whether I feel like calling a particular func with or without parans". Try detaching from that desire for a while and explore it plays out.
 If anything, that's an issue with template syntax, it has nothing
 to do with properties, let alone the beloved practice of abusing
 properties for the sake of things that clearly are not properties.

The implied assumption here is that if it doesn't have parens it's a property. Well it's a function call.

Right, it's a function call. So what in the world do we gain by allowing the caller to make it look like something it isn't? Nothing.

Never answer your own rhetorical question :o).

I think there's also another overrated rule that prohibits use of the word "you" ;) But fine: "Right, it's a function call. So what in the world do we gain by allowing the caller to make it look like something it isn't?"
Jan 23 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 This is a problem that other languages have *already* solved, 
 with
 well-known, well-understood solutions (ie: the "action==paren,
 data==no parem" rule). Unfortunately, despite the readily 
 available
 solution, D is still trying to wrap its head around the matter, 
 and
 winds up flailing around in a sea of issues because it is (you 
 are)
 desperately clinging to the failed (ie: it creates problems) and
 unimportant notion of "No matter what happens with properties, 
 I *must*
 be able to decide on a whim whether I feel like calling a 
 particular
 func with or without parans". Try detaching from that desire 
 for a while
 and explore it plays out.

+1 :-) Bye, bearophile
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 00:45:02 +0100
Timon Gehr <timon.gehr gmx.ch> wrote:

 On 01/23/2013 11:46 PM, Nick Sabalausky wrote:
 On Wed, 23 Jan 2013 21:29:14 +0100
 Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 1/23/13, Adam D. Ruppe <destructionator gmail.com> wrote:
 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.

About property problems, I've recently ran into this: ModuleInfo.unitTest is defined as property void function() unitTest() nothrow pure; And if I use it: foreach (m; ModuleInfo) { if (m is null) continue; if (auto fp = m.unitTest) { fp(); // calls it m.unitTest(); // doesn't call it m.unitTest()(); // calls it } } This is regardless of the -property switch. I would expect the second call to work. Anyone know if this is filed already?

Don't know if it's filed, but yea: Optional empty-parens and the practice of conflating properties with functions is riddled with corner-cases. We can either try to patch over these corner cases with increasingly detailed new rules,

What are those "new" rules? The rules we already have are sufficient. Now the compiler needs to implement them properly.

Andrei was just suggesting this: http://forum.dlang.org/post/kdpg5n$2qt2$1 digitalmars.com
 as Andrei is proposing, or we
 can just accept "the writing on the wall" (if you'll pardon my
 80's-ism) that properties != functions.

That is not even the point of this discussion. a.map!(a=>foo(a,b).map!(a=>2*a)())().days().ago().writeln()

First of all, spacing helps: a.map!( a => foo(a,b).map!(a=>2*a)() )().days().ago().writeln() So does not trying to cram everything into a one-liner: auto descriptiveName = a => foo(a,b).map!(a=>2*a)(); a.map!descriptiveName().days().ago().writeln() And then there's a few () in there, but not only do I fail to see how those hurt anybody, they make perfect sense since "days", "ago" and "writeln" are not data access, they're actions (even if maybe a little too cutely-named in the case of "ago"). (Of course, I'd question the meaningfulness and feasability of passing the "days" type constructor a range instead of a scalar, but I get that that's beside the point ;) )
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 22:53:45 +0100
Timon Gehr <timon.gehr gmx.ch> wrote:
 
 Likewise, there is no problem with 2.days.ago.
 
 Clock.currTime() - dur!"days"(2) is more verbose without being more
 clear.

*IMO*: The problem with that latter example is just (what I see as) some unfortunate choices for naming and such. Alter it like this: now() - days(2) And I think that's no longer overly verbose, has great clarity, and does so without feeling too cute or magical. Of course, like I said before, I could live with 2.days.ago, but it's not really what I'd prefer.
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 22:59:38 +0100
"monarch_dodra" <monarchdodra gmail.com> wrote:
 
 --------
 IMO: We should be able to keep the optional parenthesis for all 
 functions (except maybe those that return delegates).

I'm not a fan of that as I think the need for special-casing of functions returning delegates is not worth what I still don't see as a benefit. Side note: I know at least one person here likes this [ ;) ], but I really hate code like: foo.doStuff; foo.makeFizzBar; foo.updateBlorg; Have to do a double-take every time. Just looks like a bunch of no-ops, and sets off mental red flags every single time.
 Things that 
 are marked as property, however, MUST respect two things:
 1) properties should *NEVER* have parentheses.

Agreed
 2) you should not be able to take the address of a property 
 function.

Agreed One could argue that you should be able to take the address of a property, just like any other function, and to end up with a delegate. But if you need to do that you can just use a lambda. It may be an extra function call and indirection, but that's optimizable out, right? That way you get to eat your delegate cake and still have no accedental surprises arising from "&foo.bar" being an unexpected type.
 3) The "a.prop = value" should call "a.prop(value)" IFF prop is 
 declared property.
 

Agreed I would also add: 4) Setters must be called like "a.prop = value", never "a.prop(value)" 5) Finally get rid of the damn -property switch (or maybe just make it a no-op for build script backwards-compatibility, at least for a few releases)
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 23:19:17 +0100
"Adam D. Ruppe" <destructionator gmail.com> wrote:
 (yup, I'm kinda for writeln = str; because you can throw that in 
 without hunting for the end of the expression to put in the close 
 paren.

I think that shows how different editors or even just personal typing styles can affect our coding style. For me, I'll do stuff like: str~isFoo? [Oops, that's right, I need parens around that '?:'] <CTRL + (LEFT-ARROW x2)> ( <END> ) <LEFT-ARROW> [Now looks like: str~(isFoo?|) <--pipe is cursor] trueCond:falseCond <END> [Now looks like: str~(isFoo?trueCond:falseCond)| ] [Hmm, I want to writeln that...] <HOME> writeln( <END> ); Final: writeln(str~(isFoo?trueCond:falseCond)); Probably not surprising that I avoid trying to code on anything but a full-size keyboard with a proper section of <arrows, del, home, end, pgup, pgdn>, because coding on, say, a laptop keyboard (even one with a numpad) is a huge slowdown. I'd gladly give up the numberpad on my laptop if I could get a standard arrows/home/end/etc section instead, rather than the impractical "mini-keys in awkward faraway places" they currently use for such keys. Heh, actually, case in point, take a look at my normal work setup: http://66.228.38.161/download/img/jobs-would-have-hung-employees-for-doing-this.jpg (Yes, I need to get a wireless keyboard/trackball ;) )
 
 I see no reason to change the current behavior for non- property.
 
 Now, for  property setters, we might use them for other 
 operations too.
 
  property int a() { return 10; }
  property void a(int v) { ... }
 
 a += 10;
 
 should be transformed into a(a() + 10); which is not currently 
 done.

Geez, we still don't have that?
Jan 23 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
Alexandrescu wrote:
 We need a good DIP on this. UFCS has destroyed all arguments in 
 favor of requiring parens. There is no question we must do 
 this. Anyone inclined toward writing a detailed DIP?

 Andrei

What about optional parens on non-UFCS calls, is there a case for this? Honest question. I'm inclined to writing a DIP.
Jan 23 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 24 January 2013 at 04:00:44 UTC, Nick Sabalausky 
wrote:
 On Wed, 23 Jan 2013 22:59:38 +0100
 "monarch_dodra" <monarchdodra gmail.com> wrote:
 
 --------
 IMO: We should be able to keep the optional parenthesis for 
 all functions (except maybe those that return delegates).

I'm not a fan of that as I think the need for special-casing of functions returning delegates is not worth what I still don't see as a benefit. Side note: I know at least one person here likes this [ ;) ], but I really hate code like: foo.doStuff; foo.makeFizzBar; foo.updateBlorg; Have to do a double-take every time. Just looks like a bunch of no-ops, and sets off mental red flags every single time.
 Things that are marked as property, however, MUST respect two 
 things:
 1) properties should *NEVER* have parentheses.

Agreed

The irony here though is that "-property" enforces the opposite :/ (non-properties always have parens...)
Jan 23 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 07:20:22 monarch_dodra wrote:
 The irony here though is that "-property" enforces the opposite
 
 :/ (non-properties always have parens...)

-property is thoroughly broken. It was supposed to do strong property enforcement (never parens with properties and always parens with functions), but it doesn't. But not only does it not do strong enforcement right, it doesn't even do weak enforcement right, as weak enforcment would mean enforcing that property functions don't get called with parens but functions could be called either way. And of course it's buggy in how well it even enforces the part that it's currently trying to enforce. Given the increasing sentiment against strong property enforcement (due in large part to UFCS), I'd expect that what we'll ultimately end up with is weak property enforcement, but -property obviously doesn't help with that at all. Much as I'd love to have strong property enforcement, -property really doesn't help us much at this point. - Jonathan M Davis
Jan 23 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 01:33:29 Andrei Alexandrescu wrote:
 If you find this not wanting and not improvable we might have reached an
 irreducible position.

I think that it's been clear for some time that there's no way to please both the folks who want strong property enforcement and those who want weak property enforcement. One side is going to lose out, and much as I'm very much in favor strong property enforcement (and Nick clearly is as well), I think that it's fairly clear at this point that the majority of folks arond here are not (in great part due to UFCS). Not to mention, sorting out proper property enforcement has taken so long given all of the other priorities, that doing strong property enforcement would probably break quite a lot of code at this point. - Jonathan M Davis
Jan 23 2013
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
I've always secretly hated the ambiguity in D's syntax. E.g:

foo.bar

What could foo and bar be? D has many more answers than C++:

                     D           C++
                     foo bar     foo bar
Module/Namespace    x   x
Type                x   x
Variable            x   x       x   x
Method                  x
Free function       x   x

For this reason I initially agreed with Nick Sabalausky on 
disallowing calling non-property functions without parenthesis.

...but now I'm thinking that this ambiguity stops being an issue 
once we have an IDE that can render different things in different 
colors (or different fonts or with other visual cues if you're 
color-blind). Color is a much stronger and faster visual cue than 
having parenthesis at the end of a name. For this reason, I think 
that it's fine to allow non-property functions to be called 
without parenthesis. But I still think that property functions 
should not be allowed to be called with parenthesis.
Jan 24 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 24 January 2013 at 08:41:34 UTC, Jacob Carlborg 
wrote:
 On 2013-01-23 22:59, monarch_dodra wrote:

 In this context, what does it mean then to have something be 
 "a property" ?

 I think we should remember what " property" (as I understood 
 it) is
 meant for: a function that can emulate being a object. The 
 de-facto
 example being "front".

It's for a method emulating being a field/public instance variable.
 The "final" objective (as I understood it), is that you can 
 publish your
 interface, and later, swap object/members for functions (and 
 vice versa).

You cannot do this in D. There are at least two issues: 1. You cannot replace a non-final property, i.e. a method, with a field. Someone might have overridden the method in a subclass. In other languages like Scala a public instance variable is implemented as a method. In these cases you can switch freely between a property and an instance variable.

Ture, it *is* a one way street, but would at least be a street none the less. Imagine you used to have a field in the base class "myInt", but now you need a virtual myInt. You can replace your field with a virtual property that returns by ref. Your old code: //---- int* p = &myClass.myInt; //---- Will still work, but the actual field will be resolved at runtime. This does require my "point 2" to be implemented though: You can't take the address of a property. If "myInt" was implemented as a simple function, here, you'd end up taking the address of the function myInt, and break code.
 2. There are some issues with fields of a struct type being 
 changed to a property, since they are usually passed by value. 
 Example:

They shouldn't have to. That'd be an interface change. If you do that, then breakage is inevitable, property or no.
 If you instead return by reference it will work, but then you 
 can also set "bar" directly, bypassing the setter.

I think this is a limitation. If bar is a property, and has a setter, then "bar = 5" should *always* call the setter, regardless of ref or not. IMO, it not currently doing so is a limitation
Jan 24 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 24 January 2013 at 06:34:58 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 1:18 AM, monarch_dodra wrote:
 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
 Alexandrescu wrote:
 We need a good DIP on this. UFCS has destroyed all arguments 
 in favor
 of requiring parens. There is no question we must do this. 
 Anyone
 inclined toward writing a detailed DIP?

 Andrei

What about optional parens on non-UFCS calls, is there a case for this? Honest question.

Let them be.
 I'm inclined to writing a DIP.

That would be great! Andrei

We actually have one, which I think I agree with: http://wiki.dlang.org/DIP21 The gist of the DIP is that something marked with property is always and immediately expanded into a call. This fits into my proposal of: 1) properties never have parens (they are added by the compiler) 2) You can't take the address of a property function: "&foo" would become "&foo()", so you'd always get the address of the return value. - make parens optional for everything else. - allow the "foo = 5" rewrite into "foo(5)" only for properties. -- Note that if foo is a non-property that returns by ref, then "foo = 5" remains legal -- However, "writeln = 5" would be illegal. I think properties is a really cool & powerful concept. It got conflated into "optional parens". This doesn't mean we should just "take it out back"...
Jan 24 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 09:47:32 +0100
Jacob Carlborg <doob me.com> wrote:

 On 2013-01-24 06:16, Nick Sabalausky wrote:
 
 Heh, actually, case in point, take a look at my normal work setup:

 http://66.228.38.161/download/img/jobs-would-have-hung-employees-for-doing-this.jpg

 (Yes, I need to get a wireless keyboard/trackball ;) )

That's not a good work setup, in any way. Close the laptop and get a real, external monitor, or two.

I do, just not hooked up ATM. Been meaning to.
Jan 24 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 09:52:38 +0100
Jacob Carlborg <doob me.com> wrote:

 On 2013-01-24 00:16, Nick Sabalausky wrote:
 
 I'll certainly grant that, insofar as the written order is backwards
 from the execution order. I think the "ago" is that part that bugs
 me the most. It's too clever. I could live with "2.days", but I'd
 prefer "days(2)" since that looks like a type constructor, and
 "days" isn't a property of 2. Maybe "2.toDays()", but at that point
 I'd still rather just do the simpler "days(2)".

If you don't have "ago" how would you determine the differences compared to the opposite,

now - blah vs. now + blah
 which looks like this in Ruby on Rails:
 
 time = 2.days.from_now
 
 "2" is the duration, "days" is the unit and ago/from_now indicates if 
 it's positive or negative.
 

Jan 24 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-00-24 05:01, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  
wrote:

 On Wed, 23 Jan 2013 22:59:38 +0100
 "monarch_dodra" <monarchdodra gmail.com> wrote:
 --------
 IMO: We should be able to keep the optional parenthesis for all
 functions (except maybe those that return delegates).

I'm not a fan of that as I think the need for special-casing of functions returning delegates is not worth what I still don't see as a benefit. Side note: I know at least one person here likes this [ ;) ], but I really hate code like: foo.doStuff; foo.makeFizzBar; foo.updateBlorg; Have to do a double-take every time. Just looks like a bunch of no-ops, and sets off mental red flags every single time.

Amen! I do understand Adam's view that foo.bar(10).baz(5) be allowed, but that could be written with(foo){bar=10;baz=5}. Admittedly more verbose, but also clearer. On that topic, I occasionally do miss C#'s object initializers, particularly because they could allow for immediate creation of many const and immutable values. -- Simen
Jan 24 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 05:16:32 UTC, Nick Sabalausky 
wrote:
 I think that shows how different editors or even just personal
 typing styles can affect our coding style. For me, I'll do 
 stuff like:

Aye, I think this applies to my non-caring about identifier name length too - I use tab completion in my editor. I've tried some of those auto parens things, and it just confuses me. I guess I could get used to it (I recently started playing one of those newer shooter games. I come from Perfect Dark on the N64, so I'm used to what Halo called "legacy controls". The new controls were totally unusable to me.... but I was forced to stick with it for a while and now kinda am ok. I just hope it hasn't ruined my aptitude at PD controls! Perfect Dark is still the best shooter ever.). But still, it isn't that big of a deal, my way works very well 99.9% of the time.
 Probably not surprising that I avoid trying to code on anything 
 but a full-size keyboard with a proper section of <arrows, del,
 home, end, pgup, pgdn>, because coding on, say, a laptop
 keyboard (even one with a numpad) is a huge slowdown.

Yeah, I spend some time on a laptop (a little 12" one too) and it isn't as nice as the real keyboard, but I got one with a decent key placement and remapped some of the keys to fit the muscle memory anyway, so it isn't that bad. The worst thing about my laptop keyboard is the 9 key doesn't work right and needs extra force. Since that's also (, ugh! But I'm cheap so whatever.
 Heh, actually, case in point, take a look at my normal work 
 setup:

lol, I got one of those ipads as a gift last year. I found it totally useless except for the angry birds and watching some video streams, i.e. not work at all. But, I wanted a computer in my other room last week. My laptop is never at home, so I looked into buying something. And my decision was sure to be painful to Steve Jobs: I bought an off brand usb thingy for the pad, and a full sized (Microsoft brand LOL) keyboard. Combined with an ssh app for the pad thingy (death to lowercase i), it became almost useful. So I was only in for $20 and now have a halfway usable portable computer. No mouse though. Yes arrow keys (thank god, the morons at Apple refuse to put them in, which makes this thing utterly useless for anything other than their small set of sanctioned activities. OK, that apparently serves millions of people and turns an enormous profit, but that doesn't matter to /me/!). But, surprisingly, no to home and end! Maybe it is just mapped wrong though, I haven't looked into the details. Still though, 3/4 of a real keyboard is lightyears beyond the touch nonsense, and the price for the hack beat the crap out of buying a real computer.
 Geez, we still don't have that?

We spend too much time arguing over optional parenthesis!
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
Alexandrescu wrote:
 We need a good DIP on this. UFCS has destroyed all arguments in 
 favor of requiring parens. There is no question we must do 
 this. Anyone inclined toward writing a detailed DIP?

Let me strongly disagree. Language feature should never be introduced where library solution is possible. And library solution is possible. And opDispatch makes it possible.
Jan 24 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:
 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
 Alexandrescu wrote:
 We need a good DIP on this. UFCS has destroyed all arguments 
 in favor of requiring parens. There is no question we must do 
 this. Anyone inclined toward writing a detailed DIP?

Let me strongly disagree. Language feature should never be introduced where library solution is possible.

C has strings as a concept and C++ as a library solution. Which strings are better: C, C++ or D?
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 14:53:49 UTC, Maxim Fomin wrote:
 On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:
 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
 Alexandrescu wrote:
 We need a good DIP on this. UFCS has destroyed all arguments 
 in favor of requiring parens. There is no question we must do 
 this. Anyone inclined toward writing a detailed DIP?

Let me strongly disagree. Language feature should never be introduced where library solution is possible.

C has strings as a concept and C++ as a library solution. Which strings are better: C, C++ or D?

D string string is not builtin. string is merely a thing in D. D have builtin slices, which is a generic feature that is used with whatever you want.
Jan 24 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Thursday, 24 January 2013 at 15:02:02 UTC, deadalnix wrote:
 On Thursday, 24 January 2013 at 14:53:49 UTC, Maxim Fomin wrote:
 On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:
 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
 Alexandrescu wrote:
 We need a good DIP on this. UFCS has destroyed all arguments 
 in favor of requiring parens. There is no question we must 
 do this. Anyone inclined toward writing a detailed DIP?

Let me strongly disagree. Language feature should never be introduced where library solution is possible.

C has strings as a concept and C++ as a library solution. Which strings are better: C, C++ or D?

D string string is not builtin. string is merely a thing in D. D have builtin slices, which is a generic feature that is used with whatever you want.

Perhaps a bad example but I disagree that any feature that can be implemented as a library, should not be introduced as a language feature. Some features needed to be embedded into language because as a library features they would be very ugly.
Jan 24 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 24 Jan 2013 09:20:44 +0100
schrieb Jacob Carlborg <doob me.com>:

 On 2013-01-24 03:02, Nick Sabalausky wrote:
 
 foo.bar() // Perform action
 foo.bar   // Access data

Who says it has to be like this.

.NET guidelines since .NET 1.1 for example: "In general, methods represent actions and properties represent data." (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 15:32:36 UTC, Maxim Fomin wrote:
 Perhaps a bad example but I disagree that any feature that can 
 be implemented as a library, should not be introduced as a 
 language feature. Some features needed to be embedded into 
 language because as a library features they would be very ugly.

Yes, that is true. But in our case, the library solution isn't ugly.
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 16:27:02 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 3:38 AM, Tommi wrote:
 I've always secretly hated the ambiguity in D's syntax. E.g:

 foo.bar

 What could foo and bar be? D has many more answers than C++:

 D C++
 foo bar foo bar
 Module/Namespace x x
 Type x x
 Variable x x x x
 Method x
 Free function x x

Nah, C++ has also namespace, inner classes and function-local classes... lookup and resolution are actually more complicated than D.

No. C++ has no forward references, no UFCS, and no way to introduce new symbols during semantic analysis. C++ is an horrible beast, but on the identifier side, D is far worse.
Jan 24 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 24 January 2013 at 16:30:45 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 4:28 AM, monarch_dodra wrote:
 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21

Walter convinced me last night that eliminating property is more sensible.

He hasn't even *tried* to address the arguments which led to the introduction of property here, though. I don't like property myself, and even less the current broken implementation, but just saying »meh, we don't need it anyway« without even reviewing the reasons that led to its introduction is the worst possible way of handling the situation. And if this has already been done, why not summarize the rationale for removing it anyway here? Otherwise, everybody has to dig through numerous threads in the archives in order to even *join* the discussion. I'm sure many people just shouting "+1" here have not considered the behavior in the various special cases involved. In any case, I'm looking forward to seeing these points addressed in a DIP on the topic. David
Jan 24 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 11:25:38 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/24/13 3:20 AM, Jacob Carlborg wrote:
 On 2013-01-24 03:02, Nick Sabalausky wrote:

 foo.bar() // Perform action
 foo.bar // Access data

Who says it has to be like this.

Agreed. It's an implied, unstated assumption - the most dangerous kind.

It's dangerous to *break*, not to follow.
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 11:30:46 Andrei Alexandrescu wrote:
 On 1/24/13 4:28 AM, monarch_dodra wrote:
 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21

Walter convinced me last night that eliminating property is more sensible.

Well, that's bad news. It's bad enough that property hasn't been properly sorted out, but getting rid of it completely disregards the problems that it's trying to solve. Getting rid of property would be a horrible move IMHO. - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 24 Jan 2013 20:26:25 +0100
schrieb "Jonathan M Davis" <jmdavisProg gmx.com>:

 On Thursday, January 24, 2013 11:30:46 Andrei Alexandrescu wrote:
 On 1/24/13 4:28 AM, monarch_dodra wrote:
 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21

Walter convinced me last night that eliminating property is more sensible.

Well, that's bad news. It's bad enough that property hasn't been properly sorted out, but getting rid of it completely disregards the problems that it's trying to solve. Getting rid of property would be a horrible move IMHO. - Jonathan M Davis

Especially as it means that we have to deprecate property first and it'll probably stay around for at least another year.
Jan 24 2013
prev sibling next sibling parent "." <. .com> writes:
 "Right, it's a function call. So what in the world do we gain by
 allowing the caller to make it look like something it isn't?"

Jan 24 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 14:37:28 +0100
"Adam D. Ruppe" <destructionator gmail.com> wrote:

 On Thursday, 24 January 2013 at 05:16:32 UTC, Nick Sabalausky 
 wrote:
 I think that shows how different editors or even just personal
 typing styles can affect our coding style. For me, I'll do 
 stuff like:

Aye, I think this applies to my non-caring about identifier name length too - I use tab completion in my editor.

I tend to do a lot of copy/paste for symbol names. Maybe not as good as auto-complete, but with either of these (depending on the situation and my whims): 1. Up/Down/Ctrl-Left/Ctrl-Right/Home/End to line/word-skip to one end of ident 2. Shift-Ctrl-(Left or Right) to select ident 3. Ctrl-C (copy) 4. Up/Down/Ctrl-Left/Ctrl-Right/Home/End to line/word-skip to target 5. Ctrl-V (paste) 6. Goto 4 if needed (Less frequent, but nicer for long distances or if my hand is already on the mouse): 1. Right hand: Double-click ident 2. Left hand: Ctrl-C (copy) 3. Right hand: Click target 4. Left hand: Ctrl-V (paste) 5. Goto 3 if needed Been doing both long enough that muscle memory makes either of them quick, natural operations. Ctrl-Arrow and Home/End are fucking awesome :) Anyway, point being, with either of those, longer idents don't bother me much either (unless it gets the the point where line lengths for simple things get too long, or I can't distinguish between the idents without reading them).
 I've tried some of those auto parens things, and it just confuses 
 me.

They're not my thing either. Same thing for when they auto-indent big checks of code (I can do that myself with Shift-Ctrl-Up/Down and then Tab). It certainly *could* be helpful for some, but I don't like when the editor tries to anticipate my typing style and changes things around while I'm typing. It's like having someone reach over my shoulder while I'm working and "help out" by banging on the keyboard uninvited without them having any idea what my muscle memory, habits and concious intent are just about to make me type. I do very much like having <Enter> copy the same indentation of the previous line into the newly-inserted line, but that's about it.
 I guess I could get used to it (I recently started playing 
 one of those newer shooter games. I come from Perfect Dark on the 
 N64, so I'm used to what Halo called "legacy controls". The new 
 controls were totally unusable to me.... but I was forced to 
 stick with it for a while and now kinda am ok. I just hope it 
 hasn't ruined my aptitude at PD controls! Perfect Dark is still 
 the best shooter ever.).

Yea, those "Halo" controls are usually just called "Dual Analog" first-person controls. I think they're an abomination compared to having a *real* pointing device, like a mouse/trackball or Wii's IR pointing (Yea, the Wii's gesture recognition is crap as everyone says, *but* the IR pointing works great and is a killer feature IMO). But when I'm playing some first-person game that won't let me use a real pointing device (ex: most PS3 first-persons, all XBox1 first-persons) then I've always found the dual-analog to at least be a huge improvement over the older single-analog designs. But the notable exception for me is Metroid Prime: The single-analog controls in 1 and 2 worked great for that game, and 3's IR-pointing was botched and crappy - I hated it. Red Steel 1 and Call of Duty 3 did IR pointing the *right* way, even though I never liked Call of Duty 3 overall, and Red Steel's controls *did* turn shitty during the unfortunate sword battles. But you're right, Perfect Dark *is* a great game. :)
 Heh, actually, case in point, take a look at my normal work 
 setup:

lol, I got one of those ipads as a gift last year. I found it totally useless except for the angry birds and watching some video streams, i.e. not work at all.

Yea. For work, I spent most of 2012 in possession of a loaner iPhone 4 (and some Android thing). I got the urge to hurl it into the nearest concrete wall every time I used it. I don't think there was a single thing about it I liked. At the end, packaging it up to send back felt like Christmas morning :) Angry Birds gets a lot of flack for, I guess, being a bit too popular and overly-marketed. But thing about it though, is it's pretty much the only phone/tablet game out there that *isn't* total crap. (And the "In Space" one is actually quite good.) All the other games on those devices either have those completely unusable "soft gamepad" abominations, or just simply have extremely minimal gameplay. And most of them are just clones of each other. I do kinda want to get a WiFi-only Android thingamadoo though. Not because I like it (I don't - it was clearly designed by people who considered the iPhone to be perfection), but only because I could use a new camera and a WiFi-connected PDA, and PalmOS is unfortunately dead and therefore no longer an option.
 But, I wanted a computer in my other room last week. My laptop is 
 never at home, so I looked into buying something.
 
 And my decision was sure to be painful to Steve Jobs: I bought an 
 off brand usb thingy for the pad, and a full sized (Microsoft 
 brand LOL) keyboard. Combined with an ssh app for the pad thingy 
 (death to lowercase i), it became almost useful.
 

Heh, yea. Having ultra-mobile SSH is pretty damn cool. Part of why I want a new PDA.
 So I was only in for $20 and now have a halfway usable portable 
 computer. No mouse though. Yes arrow keys (thank god, the morons 
 at Apple refuse to put them in, which makes this thing utterly 
 useless for anything other than their small set of sanctioned 
 activities. OK, that apparently serves millions of people and 
 turns an enormous profit, but that doesn't matter to /me/!). But, 
 surprisingly, no to home and end!
 

/me nods head in total agreeance. Manufacturers figure "Ehh, *most* people don't use them and we don't give a shit about the rest, so let's just throw them away." Which is going to lead to a need to start seeing special "Programmer Keyboards" in the US like other countries have. Of course, these will probably end up being as expensive as the rip-off "Gamer Keyboards" that are out there. In computers, companies have actually managed to turn "knowing what you're doing" into a liability.
 Still though, 3/4 of a real keyboard is lightyears beyond the 
 touch nonsense,

Oh absolutely. More like "non-touch" though. It's absolutely insane that these companies toss around the word "touch" like crazy despite the clear fact that they're systematically *eliminating* any and all touch sensation, they're not adding one damn bit of touch. Thay're *not* "touch", they're very much *anti*-touch. Idiots.
 and the price for the hack beat the crap out of 
 buying a real computer.
 

Not if you didn't already have the iPad. Those things are expensive. I got my laptop last spring (with dual-core, 64-bit, 4GB RAM, 320GB HDD, USB 3, HDMI/VGA-out, DVD burning, Intel HD graphics which is actually quite capable for many games, not that I needed that), for only $340. Add in a few cheap accessories from MicroCenter (by far the best computer store I've ever found - as long as you ignore the salesmen), and I think it came out pretty well. Still not nearly as portable as a netbook, and I *hate* the 16:9 screen that's become the ONLY option (unless you want one of those completely moronic 2.x:1 screens that some companies actually offer) but hey, beats the old desktop, and a damn better price than the ~$2000 that was typical for a decent portable 12/13 years ago when I'd bought my first laptop (I'd made sure to splurge for the active-matrix screen ;) ). Speaking of, what's a good Linux for laptops these days? I'm anxious to get rid of this horrid Win7 that was preinstalled (XP is genuinely a possible option for me). Most of my recent Linux experience is debian-based ((Ku/U)buntu a few years back and Debian 6 more recently). I'm planning to give Mint a test drive in a VM. Is that any good for laptops, or is "laptop" a non-issue for linux these days?
 Geez, we still don't have that?

We spend too much time arguing over optional parenthesis!

Heh :) Honestly, I'm *really* surprised that I didn't notice the continued lack of += on properties. Must have gotten used to avoiding it or something, I guess? I dunno.
Jan 24 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 15:14:36 Andrei Alexandrescu wrote:
 On 1/24/13 2:26 PM, Jonathan M Davis wrote:
 On Thursday, January 24, 2013 11:30:46 Andrei Alexandrescu wrote:
 On 1/24/13 4:28 AM, monarch_dodra wrote:
 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21

Walter convinced me last night that eliminating property is more sensible.

Well, that's bad news. It's bad enough that property hasn't been properly sorted out, but getting rid of it completely disregards the problems that it's trying to solve. Getting rid of property would be a horrible move IMHO.

would be appropriate. So we are looking at _changing_ the language, not simply ignoring property.

Then what do you mean to do with property? Regardless of what we do with paren-less function calls, I think that it's important to have explicit properties - particularly when you consider enhancement requests such as http://d.puremagic.com/issues/show_bug.cgi?id=8006 (which we probably should have implemented ages ago). - Jonathan M Davis
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 18:01:30 UTC, Andrei Alexandrescu 
wrote:
 On 1/24/13 9:25 AM, deadalnix wrote:
 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
 Alexandrescu wrote:
 We need a good DIP on this. UFCS has destroyed all arguments 
 in favor
 of requiring parens. There is no question we must do this. 
 Anyone
 inclined toward writing a detailed DIP?

Let me strongly disagree. Language feature should never be introduced where library solution is possible.

Absolutes are difficult positions in language design.

This is why I used should and not must.
 And library solution is possible. And opDispatch makes it 
 possible.

Problem is, a lot of code would need to add opDispatch. I don't think that's good language design.

Not at all, you can provide one via UFCS.
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 18:12:22 UTC, Andrei Alexandrescu 
wrote:
 Well if D is worse, should we give up on forward references, 
 UFCS, or mixins?

No, I don't think we should drop them. I'm just mentioning that identifier resolution in harder in D than in C++ , but never said that identifier resolution should be easy.
Jan 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 19:36:35 UTC, Dmitry Olshansky 
wrote:
 The same argument was brought about overloading  operators, 
 about overloading functions, etc. In other words the argument 
 is WYSIWYG, but humans inherently think in overloaded notions 
 and take obvious shortcuts
 just about everywhere.

That is not because it is ambiguous, where . overload behavior for pointer isn't. Such behavior would be like if pointer dereferenced automagically and you add to put & everywhere to not dereference them. That would be an horrible behavior, as well as calling function automatically is an horrible behavior. So we want to avoid () for convenience. I have noting against convenience, but here it is plain wrong : - We have 2 syntax to do the same thing. - If the return value is callable, it is unclear what is done. - We need something to NOT call the function, as it is called magically. Let's introduce &funName syntax and mess up with another feature. - It is now unclear when we take the return address or the address of the function. - It is also not clear how to pass a function as parameter (we have seen the case recently). - Depending on the callable, () and & have different behaviors, which is error prone, harder to learn for newcomer, harder for generic code, and exactly what everybody hate about C++ . I have nothing against convenience, and like very much the pointer + dot behavior. I actuelly proposed something similar with functions : function.identifier can call the function without (), which is the equivalent of the pointer thing in term of convenience. Going further inherently mess up with other features of the language.
Jan 25 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Jan 2013 00:11:24 +0100
schrieb Timon Gehr <timon.gehr gmx.ch>:

 On 01/24/2013 04:45 PM, Johannes Pfau wrote:
 Am Thu, 24 Jan 2013 09:20:44 +0100
 schrieb Jacob Carlborg <doob me.com>:

 On 2013-01-24 03:02, Nick Sabalausky wrote:

 foo.bar() // Perform action
 foo.bar   // Access data

Who says it has to be like this.

.NET guidelines since .NET 1.1 for example: "In general, methods represent actions and properties represent data." (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).

This is not C#.

I think I misunderstood the question. If the question was whether the parenthesis mark an action as opposed to data access, then my statement is of course void. (But it's a tradition from C that () mark function calls). I thought he meant properties should be used for data access. This is almost by definition: Java used setX /getX, C# formalized that into properties, D took properties from C#. Properties where always used for data access, if you don't use properties for data access but for other things the whole concept doesn't make sense. So in that case "this is C#". Properties are polymorphic fields, nothing more nothing less. The D implementation is horrible though as you can't do stuff like x.field++. However, how would you implement this without properties and fields: x.value++; //Field or property x.setValue(x.getValue()++); //How ugly... x.setValue(x.getValue++); //Really ugly (optional parentheses func call) You can't allow these rewrites for normal functions, it'll be a disaster and this is why we need properties. And it's also the reason why properties are data: they're fields and fields are data.
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Thursday, 24 January 2013 at 23:11:25 UTC, Timon Gehr wrote:
 This is not C#.

Jan 25 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 23:36:30 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:
 
 These days properties imply an action of, well, obtaining said value.
 If it's a wrapper as in "return zis variable" something is wrong
 already.
 

I agree in principle, but unfortunately "return zis variable" getters are often needed because no major language (that I know of) offers any other way to create data that's privately-writable and publicly-read-only - a very common need. Ie, that's the "something" that "is wrong already": the lack of a simple built-in "The public can only read this, but I can R/W it." to obviate an extremely common idiom.
Jan 25 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 26 Jan 2013 12:33:11 +0100
Jacob Carlborg <doob me.com> wrote:

 On 2013-01-25 20:27, Nick Sabalausky wrote:
 
 I agree in principle, but unfortunately "return zis variable"
 getters are often needed because no major language (that I know of)
 offers any other way to create data that's privately-writable and
 publicly-read-only - a very common need.

 Ie, that's the "something" that "is wrong already": the lack of a
 simple built-in "The public can only read this, but I can R/W it."
 to obviate an extremely common idiom.

In Ruby one would do: class Foo attr_reader :foo end This would create a getter and an instance variable. Internally one can write directly do the instance variable, or create a setter: class Foo attr_reader :foo private def foo= (value) # code end end The equal sign indicates the method is a property. Not that "attr_reader" is not a language feature, it's implemented in the core library. There are also functions available for getter and both getter and setter. In D, I would like to see something like this: property(get, set) int a; property(get) int b; property(set) int c; property int d; // same as "a" This would create a getter and/or setter and an instance variable. One could also experiment with the protection attributes like this: public property(get, protected set) int a; One way could affect the instance variable, the other way to affect the getter/setter implementation.

Interesting. Although with that in mind it seems my earlier statement is not entirely true. There are languages that offer a "publically read-only" feature: C# and Haxe. I think it just didn't occur to me because they do it via shorthand versions of their property syntaxes.
Jan 26 2013