February 27, 2013
On Tuesday, 26 February 2013 at 23:40:09 UTC, Timon Gehr wrote:
> The DIP serves as specification for later compiler implementation. If it is not formal enough, the implementation may miss corner cases.
>

One of the goals of the DIP is precisely to avoid corner cases, as they are a pain both for programmer and language implementers.

>> Languages are designed for programmers in first place, not compilers.
>>
>
> Even if that was considered unequivocally true, it would not render language specification unnecessary.
>

Language spec is a contract between the programmer and language implementers. It is highly relevant for both.
February 27, 2013
On Tuesday, 26 February 2013 at 17:09:31 UTC, 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.
>
> 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.
>

For the .identifier part, it isn't ambiguous as function don't have members, and it has been proven to work well with automatic pointer dereferences. For the foreach case, it is invalid to pass a function anyway, so no ambiguity here. It also quite heavily used.
February 27, 2013
2013/2/27 Jonathan M Davis <jmdavisProg@gmx.com>

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


I agree with Jonathan. DIP27 is a recurrence of C's mistake.
It would remove a language future, and breaking much existing code, and
then introduces nothing. Certainly compiler implementation may be
simplified a little by doing it, however it is too small benefit than the D
world destruction.

Kenji Hara


February 27, 2013
On 2/26/13 10:33 PM, kenji hara wrote:
> 2013/2/27 Jonathan M Davis <jmdavisProg@gmx.com
> <mailto:jmdavisProg@gmx.com>>
>
>     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.
>
>
> I agree with Jonathan. DIP27 is a recurrence of C's mistake.
> It would remove a language future, and breaking much existing code, and
> then introduces nothing. Certainly compiler implementation may be
> simplified a little by doing it, however it is too small benefit than
> the D world destruction.
>
> Kenji Hara

Agreed. I think it's safe to close it.

Andrei
February 27, 2013
On Wednesday, 27 February 2013 at 03:46:44 UTC, Andrei Alexandrescu wrote:
> On 2/26/13 10:33 PM, kenji hara wrote:
>> 2013/2/27 Jonathan M Davis <jmdavisProg@gmx.com
>> <mailto:jmdavisProg@gmx.com>>
>>
>>    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.
>>
>>
>> I agree with Jonathan. DIP27 is a recurrence of C's mistake.
>> It would remove a language future, and breaking much existing code, and
>> then introduces nothing. Certainly compiler implementation may be
>> simplified a little by doing it, however it is too small benefit than
>> the D world destruction.
>>
>> Kenji Hara
>
> Agreed. I think it's safe to close it.
>
> Andrei

Andrei, Kenji and Jonathan, can you explain what error of C did this DIP reproduce and why it is an error ?
February 27, 2013
2013/2/27 deadalnix <deadalnix@gmail.com>
>
> On Wednesday, 27 February 2013 at 03:46:44 UTC, Andrei Alexandrescu wrote:
>>
>> On 2/26/13 10:33 PM, kenji hara wrote:
>>>
>>> 2013/2/27 Jonathan M Davis <jmdavisProg@gmx.com <mailto:jmdavisProg@gmx.com>>
>>>
>>>    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.
>>>
>>>
>>> I agree with Jonathan. DIP27 is a recurrence of C's mistake.
>>> It would remove a language future, and breaking much existing code, and
>>> then introduces nothing. Certainly compiler implementation may be
>>> simplified a little by doing it, however it is too small benefit than
>>> the D world destruction.
>>>
>>> Kenji Hara
>>
>>
>> Agreed. I think it's safe to close it.
>>
>> Andrei
>
>
> Andrei, Kenji and Jonathan, can you explain what error of C did this DIP
reproduce and why it is an error ?

The mistake in C is mixing of function name and function address.
At least there is one ambiguity which appearance and meaning does not
correspond one-to-one.

In current D, the ambiguity is _already_ resolved - if you want to function address, use & operator.

As far as I see, DIP27 will overturn the chess board, remove property feature, change the meaning of 'foo', deprecate '&foo', and finally add nothing for the language users.

Kenji Hara


February 27, 2013
27-Feb-2013 09:34, kenji hara пишет:
> 2013/2/27 deadalnix <deadalnix@gmail.com <mailto:deadalnix@gmail.com>>
>  >
>  > On Wednesday, 27 February 2013 at 03:46:44 UTC, Andrei Alexandrescu
> wrote:
>  >>
>  >> On 2/26/13 10:33 PM, kenji hara wrote:
>  >>>
>  >>> 2013/2/27 Jonathan M Davis <jmdavisProg@gmx.com
> <mailto:jmdavisProg@gmx.com>
>  >>> <mailto:jmdavisProg@gmx.com <mailto:jmdavisProg@gmx.com>>>
>  >>>
>  >>>    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.
>  >>>
>  >>>
>  >>> I agree with Jonathan. DIP27 is a recurrence of C's mistake.
>  >>> It would remove a language future, and breaking much existing code, and
>  >>> then introduces nothing. Certainly compiler implementation may be
>  >>> simplified a little by doing it, however it is too small benefit than
>  >>> the D world destruction.
>  >>>
>  >>> Kenji Hara
>  >>
>  >>
>  >> Agreed. I think it's safe to close it.
>  >>
>  >> Andrei
>  >
>  >
>  > Andrei, Kenji and Jonathan, can you explain what error of C did this
> DIP reproduce and why it is an error ?
>
> The mistake in C is mixing of function name and function address.
> At least there is one ambiguity which appearance and meaning does not
> correspond one-to-one.
>

And what is the advantage of plain function name over just _always_ having a (constant) pointer to it ?

Since a compiler can inline any "call by pointer" as long as it knows it's a constant (like manifest constant in this DIP) performance and codegen isn't an issue.

I'd say the mistake in C is to:
a) introduce nebulous type that's not expressible (plain function name).
b) make things subtly different for func and &func, and let the letter be done under the covers sometimes

Killing both of these is an improvement.

> In current D, the ambiguity is _already_ resolved - if you want to
> function address, use & operator.
>
> As far as I see, DIP27 will overturn the chess board, remove property
> feature, change the meaning of 'foo', deprecate '&foo', and finally add
> nothing for the language users.
>



-- 
Dmitry Olshansky
February 27, 2013
On Wednesday, 27 February 2013 at 05:34:44 UTC, kenji hara wrote:
> The mistake in C is mixing of function name and function address.
> At least there is one ambiguity which appearance and meaning does not
> correspond one-to-one.
>

That is false. In C, function pointers are done as follow :
void foo() {
    printf("foo");
}

void (*functionPtr)(); // equivalent to D void function() functionPtr;
functionPtr = &foo; // Note the presence of & operator.

functionPtr(); // Call foo

This is why I don't understand the point the 3 of you are trying to make. Current behavior of D is much more close to C than what the DIP proposes.

This behavior is very specific to C and C++. If C's behavior was a mistake, then it an argument FOR this DIP, not against.

> In current D, the ambiguity is _already_ resolved - if you want to function
> address, use & operator.
>

D behave very much like C on that regard, so I don't really see how this can be true.

> As far as I see, DIP27 will overturn the chess board, remove property
> feature, change the meaning of 'foo', deprecate '&foo', and finally add
> nothing for the language users.
>

No, DIP27 is only about functions. It says nothing about properties. It add stable foundation we can build upon.
February 27, 2013
On Wednesday, February 27, 2013 03:23:04 deadalnix wrote:
> 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 ?

Then what happened to parenless function calls? _Both_ of the cases above need to call the function, or you're going to be breaking tons of code, and I see _zero_ useability gain here. The function's name by itself calls the function. & on the function's name gets its address. What's complicated about that? What we have right now with regards to functions and their addresses is incredibly straightforward, and I don't see any gains in simplifying it. It just sounds like you're killing parenless function calls for free functions outside of UFCS. What are you even trying to gain by making it so that a function's name and its address are conflated like this?

- Jonathan M Davis
February 27, 2013
Am 27.02.2013 06:54, schrieb deadalnix:
>> In current D, the ambiguity is _already_ resolved - if you want
>> to function
>> address, use & operator.
>>
>
> D behave very much like C on that regard, so I don't really see
> how this can be true.

void (*functionPtr)();

//both are valid and working in C
functionPtr xyz = &foo;
functionPtr zxy = foo; //<- this is solved in D