View mode: basic / threaded / horizontal-split · Log in · Help
February 27, 2013
Re: DIP27 available for destruction
On Wednesday, 27 February 2013 at 11:01:01 UTC, Timon Gehr wrote:
> I see. This problem does not occur. (There is no UFCS in the 
> above code.)
>

It occurs the same way with UFCS as they are function call at the 
end.

>>>> It may be limited to the case where expression can't be used 
>>>> as
>>>> statement because it has no effect.
>>>
>>> Then it is not worth it.
>>
>> It would kick in with the example you gave.
>
> Not necessarily, it would depend on the context of the 
> expression I gave.

That is true. Which is probably a bad thing.
February 27, 2013
Re: DIP27 available for destruction
On 02/27/2013 12:18 PM, deadalnix wrote:
> On Wednesday, 27 February 2013 at 11:01:01 UTC, Timon Gehr wrote:
>> I see. This problem does not occur. (There is no UFCS in the above code.)
>>
>
> It occurs the same way with UFCS as they are function call at the end.
> ...

This is an issue with the current DIP27, which my proposal does not have.
In case this is not clear yet, please provide code that supposedly has 
the issue.
February 27, 2013
Re: DIP27 available for destruction
On Tue, 2013-02-26 at 22:03 +0400, Dmitry Olshansky wrote:
> The fact that empty can't be "enum empty = false;" is a problem since 
> that's how infinite ranges are statically distinguished.

Thanks for the feedback on DIP26 :-)

The isInfinite template is also satisfied if empty is a static function
because of CTFE)

Best regards,

Robert
February 27, 2013
Re: DIP27 available for destruction
On Wednesday, 27 February 2013 at 07:26:47 UTC, deadalnix wrote:
> On Wednesday, 27 February 2013 at 06:15:29 UTC, dennis luehring 
> wrote:
>> 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
>
> I don't think D solved that. Only partially. Both are conflated 
> here for instance :
>
> void foo() {}
> foo(); <=> (&foo)();
>
> Is another presentation of the same conflation.
>
> The DIP propose to effectively solve that by removing 
> completely the entity represented by foo in &foo . You can't 
> have conflation with something that do not exists.

No, in D there is no conflation between this two. The fact that 
you write (&foo)() instead of foo() (if foo is pointer) says 
about it.

What Andrei, Kenji and Jonathan try to say (I guess) that 
function type in C in all cases is implicitly convertible to 
function pointer except when it is used with sizeof, Alignof and 
& operators (iso/iec $6.3.2). This is among the first differences 
I noticed when came from C.

If such implicit conversion is performed in D, taking into 
account D complexity and corner cases may lead to collisions on 
using function name - is it a pointer or a type?
February 27, 2013
Re: DIP27 available for destruction
On 02/27/2013 02:08 PM, Maxim Fomin wrote:
> ....
>
> If such implicit conversion is performed in D, taking into account D
> complexity and corner cases may lead to collisions on using function
> name - is it a pointer or a type?

It's a function.

I think the only technical problem of DIP27 outside the optional 
parentheses part is that it does not specify what is(T==function) will do.
February 27, 2013
Re: DIP27 available for destruction
On Wednesday, 27 February 2013 at 14:17:57 UTC, Timon Gehr wrote:
> On 02/27/2013 02:08 PM, Maxim Fomin wrote:
>> ....
>>
>> If such implicit conversion is performed in D, taking into 
>> account D
>> complexity and corner cases may lead to collisions on using 
>> function
>> name - is it a pointer or a type?
>
> It's a function.
>
> I think the only technical problem of DIP27 outside the 
> optional parentheses part is that it does not specify what 
> is(T==function) will do.

That is very true. To be fair, I think that is expression is an 
horrible three headed monster :D But I added it.
February 27, 2013
Re: DIP27 available for destruction
On 2/27/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
> I think the only technical problem of DIP27 outside the optional
> parentheses part is that it does not specify what is(T==function) will do.

The only problem? How about breaking every single piece of code ever
written in D?

It seems to me like people assume we can easily force people to
rewrite everything. It ain't gonna happen. This DIP was DOA from the
start.
February 27, 2013
Re: DIP27 available for destruction
On Wednesday, 27 February 2013 at 15:57:12 UTC, Andrej Mitrovic 
wrote:
> On 2/27/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
>> I think the only technical problem of DIP27 outside the 
>> optional
>> parentheses part is that it does not specify what 
>> is(T==function) will do.
>
> The only problem? How about breaking every single piece of code 
> ever
> written in D?
>
> It seems to me like people assume we can easily force people to
> rewrite everything. It ain't gonna happen. This DIP was DOA 
> from the
> start.

That is fallacy. PHP did massive breaking changes from 5 to 5 and 
still managed the change. And believe me, you'll find *WAY* more 
code written in PHP than in D even at the time.

Breaking are not a problem in themselves and this reaction tells 
us more about our inability to do the most basic release 
management than anything else.

On a more personal level, every single version of dmd break my 
code, so I'm kind of fed up when people don't want to fix actual 
broken stuff to not break code. D break code all the time, that 
is a fact already. Many breakage don't even have a good reason to 
exists (alias this syntax, I'm looking at you, but you are not 
the only one).
February 27, 2013
Re: DIP27 available for destruction
27-Feb-2013 20:24, deadalnix пишет:
> On Wednesday, 27 February 2013 at 15:57:12 UTC, Andrej Mitrovic wrote:
>> On 2/27/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
>>> I think the only technical problem of DIP27 outside the optional
>>> parentheses part is that it does not specify what is(T==function)
>>> will do.
>>
>> The only problem? How about breaking every single piece of code ever
>> written in D?
>>
>> It seems to me like people assume we can easily force people to
>> rewrite everything. It ain't gonna happen. This DIP was DOA from the
>> start.
>
> That is fallacy. PHP did massive breaking changes from 5 to 5 and still
> managed the change. And believe me, you'll find *WAY* more code written
> in PHP than in D even at the time.
>
> Breaking are not a problem in themselves and this reaction tells us more
> about our inability to do the most basic release management than
> anything else.

+1 on both counts.

It's the inability to handle breaking changes that is the most annoying.
An analogy: compare two situations.

The first one is that you see a notification on your front door that 
this day electricity might be unstable say during 6-8 P.M due to 
maintenance work. And at least you know what to expect even if it 
doesn't break a thing in the end.

The second one is that you have light constantly blink during the 
evening and your TV gets fried. Then a technician knock at you door to 
say that he's very sorry for frying  your TV box. But rest assured that 
he tried hard not to break anything and that only 0.05% of people 
experienced any problems.

Adopting the deprecation process is not good enough. Adopting and 
following it to the latter is still not good enough. Adopting, following 
and notifying people beforehand is close but not there.
The missing steps is providing a migration path and guarantees.

>
> On a more personal level, every single version of dmd break my code, so
> I'm kind of fed up when people don't want to fix actual broken stuff to
> not break code. D break code all the time, that is a fact already. Many
> breakage don't even have a good reason to exists (alias this syntax, I'm
> looking at you, but you are not the only one).

Same thoughts here. If anything compiler bugfixes are the biggest source 
of breakage in my code. That and regressions that come along.
I see it that only code that is constantly maintained (or instead is 
tied to a particular compiler version) is the only code that works today.

-- 
Dmitry Olshansky
February 27, 2013
Re: DIP27 available for destruction
On 2/27/13, deadalnix <deadalnix@gmail.com> wrote:
> That is fallacy.

void func(T...)(T args) { }

int foo() { return 1; }
float bar() { return 2.0; }

void main()
{
   func(foo, bar);  // ???
}

What will this do? If address-of on functions is banned then this must
pass functions by default, and not their return types. Which is a
complete change to what it does now.

So now you have to carefully inspect every function call because you
don't know whether you're passing a pointer to a function or you're
invoking the function and passing the return type.

How on earth does this simplify anything and justify code breakage?
1 2 3 4 5 6
Top | Discussion index | About this forum | D home