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.

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.

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.

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.

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?

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

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

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.

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.

On Wed, 23 Jan 2013 23:03:32 +0400
Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

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

int foo() {...}
int delegate() {...} bar;

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