View mode: basic / threaded / horizontal-split · Log in · Help
February 27, 2013
Re: DIP27 available for destruction
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
Re: DIP27 available for destruction
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
Re: DIP27 available for destruction
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
Re: DIP27 available for destruction
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
Re: DIP27 available for destruction
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
Re: DIP27 available for destruction
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
Re: DIP27 available for destruction
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
Re: DIP27 available for destruction
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
Re: DIP27 available for destruction
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
Re: DIP27 available for destruction
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home