Community

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

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