View mode: basic / threaded / horizontal-split · Log in · Help
January 23, 2013
Re: Make dur a property?
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.
January 23, 2013
Re: Make dur a property?
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.
January 23, 2013
Re: Make dur a property?
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.
January 23, 2013
Re: Make dur a property?
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.
January 23, 2013
Re: Make dur a property?
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?
January 23, 2013
Re: Make dur a property?
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 = ...;
January 23, 2013
Re: Make dur a property?
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
January 23, 2013
Re: Make dur a property?
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.
January 23, 2013
Re: Make dur a property?
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.
January 23, 2013
Re: Make dur a property?
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home