February 27, 2013
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
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
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
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
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
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
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
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
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
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?