January 24, 2013
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 ;) )

January 24, 2013
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.

January 24, 2013
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)


January 24, 2013
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?


January 24, 2013
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.
January 24, 2013
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...)
January 24, 2013
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
January 24, 2013
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
January 24, 2013
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
January 24, 2013
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