View mode: basic / threaded / horizontal-split · Log in · Help
February 26, 2013
Re: DIP27 available for destruction
On 02/26/2013 06:09 PM, Dicebot wrote:
> 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.
> ...

Like it or not, that is what a compiler does.

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

That part needs a complete overhaul. It is way too complex given the 
goal the DIP pursuits.

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

That actually wouldn't change.

> 3) It really needs a broad overview of semantic changes in common use
> cases and code breakage list.

I guess it breaks most projects out there.
February 26, 2013
Re: DIP27 available for destruction
On 02/26/2013 05:16 PM, deadalnix wrote:
> ...
> 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).

If breaking code is an option, this is almost fine.

Change the optional parens part to "optional parentheses are valid for 
CTFE calls", and you might have me on board. It is also simpler, less 
ad-hoc, and easier to implement than what the DIP currently states.
February 26, 2013
Re: DIP27 available for destruction
On Tuesday, 26 February 2013 at 20:42:57 UTC, Timon Gehr wrote:
> On 02/26/2013 06:09 PM, Dicebot wrote:
>> 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.
>> ...
>
> Like it or not, that is what a compiler does.

Pardon me, how is compiler relevant here? Languages are designed 
for programmers in first place, not compilers.

>> 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.
>>
>
> That actually wouldn't change.

Why? Functions does not have an address according to this DIP. 
How will you pass a callback to C code then, special case for 
"extern(C)"?
February 26, 2013
Re: DIP27 available for destruction
On 02/26/2013 10:14 PM, Dicebot wrote:
> On Tuesday, 26 February 2013 at 20:42:57 UTC, Timon Gehr wrote:
>> On 02/26/2013 06:09 PM, Dicebot wrote:
>>> 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.
>>> ...
>>
>> Like it or not, that is what a compiler does.
>
> Pardon me, how is compiler relevant here?

The DIP serves as specification for later compiler implementation. If it 
is not formal enough, the implementation may miss corner cases.

> Languages are designed for programmers in first place, not compilers.
>

Even if that was considered unequivocally true, it would not render 
language specification unnecessary.

>>> 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.
>>>
>>
>> That actually wouldn't change.
>
> Why? Functions does not have an address according to this DIP. How will
> you pass a callback to C code then, special case for "extern(C)"?

ReturnType function(ParameterTypes) is a C function pointer type in the 
ABI. That wouldn't change.

extern(C) int foo(int function() fun);

void main(){
    static int bar(int x){ return x+1; }
    foo(bar);          // ok
    foo((int x)=>x+2); // ok
}
February 27, 2013
Re: DIP27 available for destruction
On Tuesday, 26 February 2013 at 18:03:43 UTC, Dmitry Olshansky 
wrote:
> I like the simplicity and the automatic anti-boilerplate 
> "@property int blah;".
>

That isn't simplicity, that is ease. And @property isn't covered 
by the DIP.
February 27, 2013
Re: DIP27 available for destruction
On Tuesday, 26 February 2013 at 18:52:35 UTC, Dmitry Olshansky 
wrote:
> 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.

The DIP is similar to what exists in C# and Javascript, plus 
optional ().
February 27, 2013
Re: DIP27 available for destruction
On Tuesday, 26 February 2013 at 20:00:26 UTC, Jonathan M Davis 
wrote:
> 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?
>  ...
> }
>

Both are the function. None is listed in the implicit call cases. 
Are you sure we are talking about the same DIP ?

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

That is not how C works. In C, the function name represent the 
actual instruction f the function (and this is why taking the 
address of the function gives you a function pointer). This 
mechanics is reproduced in D but has no real use case (even if it 
is around for more than 40 years) and add complexity.

The DIP proposes something close to what exists in C# and 
Javascript.

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

Considering that both statement above are wrong, I think you 
should reconsider that conclusion.
February 27, 2013
Re: DIP27 available for destruction
On Tuesday, 26 February 2013 at 20:42:57 UTC, Timon Gehr wrote:
> On 02/26/2013 06:09 PM, Dicebot wrote:
>> 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.
>> ...
>
> Like it or not, that is what a compiler does.
>
>> 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. ...
>>
>
> That part needs a complete overhaul. It is way too complex 
> given the goal the DIP pursuits.
>

I have to say I'm not a big fan of it. But several people really 
seems to enjoy the ability to call function without (), so I went 
through some codebase to see where it is used most and figured 
out when it does not conflict with something else.

> I guess it breaks most projects out there.

I guess any changes to the way you call function is going to 
break a fair amount of code. This is the most basic feature. This 
is also why you really need to get it straightforward and simple.
February 27, 2013
Re: DIP27 available for destruction
On Tuesday, 26 February 2013 at 21:01:04 UTC, Timon Gehr wrote:
> On 02/26/2013 05:16 PM, deadalnix wrote:
>> ...
>> 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).
>
> If breaking code is an option, this is almost fine.
>
> Change the optional parens part to "optional parentheses are 
> valid for CTFE calls", and you might have me on board. It is 
> also simpler, less ad-hoc, and easier to implement than what 
> the DIP currently states.

Can you elaborate on that ? I'm not 100M satisfied with that part 
of the DIP, where I see everything else as a major improvement 
over current situation.
February 27, 2013
Re: DIP27 available for destruction
On Tuesday, 26 February 2013 at 21:14:48 UTC, Dicebot wrote:
> Why? Functions does not have an address according to this DIP. 
> How will you pass a callback to C code then, special case for 
> "extern(C)"?

D first class function *ARE* C function pointer already. The 
concept of taking the function address disappear, but it doesn't 
mean the function have no address anymore.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home