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

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

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

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?

I guessed it by name: http://wiki.dlang.org/DIP27

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

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.

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

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.