February 26, 2013
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
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
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
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
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
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
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
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
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
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.