View mode: basic / threaded / horizontal-split · Log in · Help
February 26, 2013
DIP27 available for destruction
Carmack said : « I will always take an aggressively simple 
approach to things » and so I did, as I love cargo cult.

More seriously, I face the need of more simplicity into D quite 
often, as the feature matrix is quite heavy.

So here is a new DIP about function call (and function call only, 
I have 2 more DIP to come, but writing them take quite a lot of 
time). I actually had the time to play around with different 
scheme, and that one seems clearly to be the simplest.

As usual, destroy, I don't expect to get unanimity on that. But I 
tried very hard to get most benefit of actual situation, 
including the possibility of optional parentheses in some 
situations (even if I'm not the biggest fan of it, I recognize 
that they are nice).
February 26, 2013
Re: DIP27 available for destruction
I like overall approach and think it really should be rule of a 
thumb for designing D features - defining simple bullet-proof 
semantics and making conclusions from it. As opposed to 
syntax-based special case coverage.

What I do find lacking in this DIP:

1) "Optional parentheses" part needs detailed description why 
exactly those cases have special handling and how are they 
different from others. Also looks like example code has errors 
there, for example, function that has no return statement and 
uint return type.

2) If you want to prohibit functions having an address, you need 
a section explaining communication with C in details in regard to 
passing function pointers.

3) It really needs a broad overview of semantic changes in common 
use cases and code breakage list.
February 26, 2013
Re: DIP27 available for destruction
26-Feb-2013 20:16, deadalnix пишет:
> Carmack said : « I will always take an aggressively simple approach to
> things » and so I did, as I love cargo cult.
>
> More seriously, I face the need of more simplicity into D quite often,
> as the feature matrix is quite heavy.
>
> So here is a new DIP about function call (and function call only, I have
> 2 more DIP to come, but writing them take quite a lot of time). I
> actually had the time to play around with different scheme, and that one
> seems clearly to be the simplest.
>
> As usual, destroy, I don't expect to get unanimity on that. But I tried
> very hard to get most benefit of actual situation, including the
> possibility of optional parentheses in some situations (even if I'm not
> the biggest fan of it, I recognize that they are nice).

I like the simplicity and the automatic anti-boilerplate "@property int 
blah;".

The fact that empty can't be "enum empty = false;" is a problem since 
that's how infinite ranges are statically distinguished.


-- 
Dmitry Olshansky
February 26, 2013
Re: DIP27 available for destruction
On 2/26/13, deadalnix <deadalnix@gmail.com> wrote:
> So here is a new DIP about function call

Where's the link? I don't see it listed: http://wiki.dlang.org/DIPs
February 26, 2013
Re: DIP27 available for destruction
On Tuesday, 26 February 2013 at 18:27:13 UTC, Andrej Mitrovic 
wrote:
> Where's the link? I don't see it listed: 
> http://wiki.dlang.org/DIPs

just added:
http://wiki.dlang.org/DIP27


"Transitional measure to mitigate breakage"

// Transitional behavior.
static assert(is(typeof(&foo) == void function());

// Error (foo has no address). Final behavior
static assert(is(typeof(&foo) == void function());

are these supposed to be different?
February 26, 2013
Re: DIP27 available for destruction
I guessed it by name: http://wiki.dlang.org/DIP27
February 26, 2013
Re: DIP27 available for destruction
26-Feb-2013 22:03, Dmitry Olshansky пишет:
> 26-Feb-2013 20:16, deadalnix пишет:
>> Carmack said : « I will always take an aggressively simple approach to
>> things » and so I did, as I love cargo cult.
>>
>> More seriously, I face the need of more simplicity into D quite often,
>> as the feature matrix is quite heavy.
>>
>> So here is a new DIP about function call (and function call only, I have
>> 2 more DIP to come, but writing them take quite a lot of time). I
>> actually had the time to play around with different scheme, and that one
>> seems clearly to be the simplest.
>>
>> As usual, destroy, I don't expect to get unanimity on that. But I tried
>> very hard to get most benefit of actual situation, including the
>> possibility of optional parentheses in some situations (even if I'm not
>> the biggest fan of it, I recognize that they are nice).
>
> I like the simplicity and the automatic anti-boilerplate "@property int
> blah;".
>
> The fact that empty can't be "enum empty = false;" is a problem since
> that's how infinite ranges are statically distinguished.

Ouch and I've reviewed an updated version of DIP 26 :)

Mh-m OK the warm-up is done, and it was nice to see a refined DIP26. 
Time to get to the new stuff...

I take it DIP27 was modeled after Scala? I think I like it but it leaves 
me wondering what properties are now and how they would fit. Eagerly 
waiting for more DIPs.

-- 
Dmitry Olshansky
February 26, 2013
Re: DIP27 available for destruction
On Tuesday, 26 February 2013 at 18:52:35 UTC, Dmitry Olshansky 
wrote:
> I take it DIP27 was modeled after Scala?

As far as I see it - better than Scala, as it uses real 
first-class function types, not just decorated classes. Wonder 
how it will interact with other paradigms though.
February 26, 2013
Re: DIP27 available for destruction
On Tuesday, February 26, 2013 17:16:37 deadalnix wrote:
> Carmack said : « I will always take an aggressively simple
> approach to things » and so I did, as I love cargo cult.
> 
> More seriously, I face the need of more simplicity into D quite
> often, as the feature matrix is quite heavy.
> 
> So here is a new DIP about function call (and function call only,
> I have 2 more DIP to come, but writing them take quite a lot of
> time). I actually had the time to play around with different
> scheme, and that one seems clearly to be the simplest.
> 
> As usual, destroy, I don't expect to get unanimity on that. But I
> tried very hard to get most benefit of actual situation,
> including the possibility of optional parentheses in some
> situations (even if I'm not the biggest fan of it, I recognize
> that they are nice).

Wouldn't this fall apart completely with auto or IFTI (implicit funtion 
template instantiation)? For instance take

auto foo(T)(T blah) {...}

int func() { return 7; }

void bar()
{
...
foo(func); //Does this call func or pass its address?
auto f = func; //Does this call func or take its address?
...
}

I believe that both Walter and Andrei have said on multiple occasions that one 
of C's big mistakes was conflating function names with their addresses, and 
this DIP appears to be trying to do exactly that. And I honestly don't see 
what it buys us. It just makes the situation with parenless function calls 
worse. At least right now, it's clear when you're dealing with a function 
pointer or a parenless function call. With this DIP, it wouldn't be.

- Jonathan M Davis
February 26, 2013
Re: DIP27 available for destruction
On 02/26/2013 09:00 PM, Jonathan M Davis wrote:
> ...
>
> auto foo(T)(T blah) {...}
>
> int func() { return 7; }
>
> void bar()
> {
>   ...
>   foo(func); //Does this call func or pass its address?
>   auto f = func; //Does this call func or take its address?
>   ...
> }
> ...

Neither.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home