On 08/22/2015 02:04 AM, deadalnix wrote:
> On Thursday, 20 August 2015 at 20:39:01 UTC, Timon Gehr wrote:
>> On 08/20/2015 10:26 PM, David Nadlinger wrote:
>>> On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote:
>>>> Having 2 empty strings evaluate differently is very unintuitive and
>>>> error-prone, in my opinion.
>>>
>>> It's even worse: http://dpaste.dzfl.pl/ba3376feca8e
>>>
>>> The arrays are equal, but their Boolean value is not.
>>>
>>> I don't get how Andrei can reconcile this with his "D avoids unforced
>>> errors" stance.
>>>
>>>   — David
>>
>> By denying that it is an error and by playing down its significance,
>> IIRC.
>> Same about [] is null, [1][1..1] is null, but {auto a=[1]; return
>> a[1..1];}() !is null and related cases.
>
> Note that even if you put that asside, D makes the difference between
> equality and identity. null check is an identity check, while truthiness
> is a value check. The semantic is not coherent.

That's also a good point.

On 08/22/2015 12:04 AM, Jonathan M Davis wrote:
> On Friday, 21 August 2015 at 21:13:35 UTC, David Nadlinger wrote:
>> On Friday, 21 August 2015 at 20:01:21 UTC, Vladimir Panteleev wrote:
>>> "This warning almost doesn't break any code!"
>>
>> It indeed doesn't break almost any code. Yours is quite the outlier.
>
> In general, it gets a bit interesting when a feature is useful if used
> correctly and gets used correctly by experts but generally screws up
> most programmers. For instance, the comma operator would be a case of
> that. If used correctly, it can be really useful, but it's so easy to
> misuse that it's generally considered bad practice to use it. And yet,
> I'm sure that there are folks out there who love it and use it correctly
> on a regular basis. That's not the norm though.
>
> - Jonathan M Davis

For the comma operator, I think it's pretty clear that the usage of ',' to separate components of a tuple would be more useful.

(With L-T-R evaluation, replacing usages of the comma operator is easy, e.g. 'a,b,c' becomes '(a,b,c)[$-1]', not to speak about the delegate option.)

On Saturday, 22 August 2015 at 21:23:19 UTC, Timon Gehr wrote:
> For the comma operator, I think it's pretty clear that the usage of ',' to separate components of a tuple would be more useful.
>
> (With L-T-R evaluation, replacing usages of the comma operator is easy, e.g. 'a,b,c' becomes '(a,b,c)[$-1]', not to speak about the delegate option.)

Which can be wrapped into a simple construct à la last(a, b, c) or similar.

On 08/23/2015 01:09 AM, deadalnix wrote:
> On Saturday, 22 August 2015 at 21:23:19 UTC, Timon Gehr wrote:
>> For the comma operator, I think it's pretty clear that the usage of
>> ',' to separate components of a tuple would be more useful.
>>
>> (With L-T-R evaluation, replacing usages of the comma operator is
>> easy, e.g. 'a,b,c' becomes '(a,b,c)[$-1]', not to speak about the
>> delegate option.)
>
> Which can be wrapped into a simple construct à la last(a, b, c) or similar.

Which can even be force-inlined.

On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote:
> Hi!
>
>
> string a = "";
> string b;
>
> writeln(a ? "a" : "null");
> writeln(b ? "b" : "null");
>
>
> This program outputs:
> a
> null
>
>
>
> What?
>
> I suppose this is by design, but are there any plans to deprecate this?

Sounds correct to me.

On Saturday, 22 August 2015 at 21:23:19 UTC, Timon Gehr wrote:
> For the comma operator, I think it's pretty clear that the usage of ',' to separate components of a tuple would be more useful.

Why not use C/C++/C# initializer syntax? Technically it's a tuple, but not related to comma operator.

On Friday, 21 August 2015 at 20:01:21 UTC, Vladimir Panteleev wrote:
> "This warning almost doesn't break any code!" Yes it flipping does. "It does break some code, but only in certain extremely specialized contexts like memory allocation!" No it's bleeping not. "Many of those warnings are probably actual bugs, you should fix your buggy code!" No, they quacking aren't. I just write code this way, because I find the empty/null distinction obvious and useful. Shocking, I know.

The distinction has its merits, but it shouldn't prevent you from seeing how it doesn't quite fit the D slice design.

On Friday, 21 August 2015 at 11:34:42 UTC, Marc Schütz wrote:
> On Thursday, 20 August 2015 at 19:41:44 UTC, Jonathan M Davis wrote:
>> On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote:
>>> if(arr != null)
>>
>> Definitely don't do that. IMHO, "== null and "!= null" should be illegal. If you really want to check for null, then you need to use "is null" or "!is null", whereas if you want to check that an array is empty, check its length or call empty. By using "== null" or "!= null", you tend to give the false impression that you're checking whether the object or array is null - which is not what you're actually doing.
>
> I disagree. `is null` is the one that should be illegal. `is` is supposed to do a bitwise comparison, but `null` is usually just a pointer/reference, while a slice consists of both a reference and a length. Which of those are compared?

No ambiguity there: D doesn't allow comparison of array with pointer.