if(arr) now a warning

[w0rp via Digitalmars-d]

On Friday, 10 April 2015 at 18:32:39 UTC, Andrei Alexandrescu 
wrote:
> On 4/10/15 10:28 AM, Steven Schveighoffer wrote:
>> On 4/10/15 11:57 AM, Andrei Alexandrescu wrote:
>>> On 4/10/15 6:26 AM, Meta wrote:
>>>> On Friday, 10 April 2015 at 12:42:47 UTC, Steven 
>>>> Schveighoffer wrote:
>>>>> Plus, adding arr.empty into object is kind of redundant. 
>>>>> The only
>>>>> reason we have arr.empty is so that it becomes a range.
>>>>>
>>>>> -Steve
>>>>
>>>> I find it extremely annoying to have to import std.array (or 
>>>> whatever
>>>> the correct module is) just to use .empty, .front and 
>>>> .popFront on
>>>> arrays. IMO they should all be in object.d.
>>>
>>> Yah, I was about to post the same. Range semantics are 
>>> embedded in the
>>> language enough to warrant this.
>>>
>>> Also empty should work for AAs.
>>
>> How should "abc".front work? Do you want to move unicode 
>> decoding of
>> char and wchar arrays into object.d? Serious question, not 
>> rhetorical,
>> because I'm not for or against it (except for the notion of 
>> changing
>> things for the sake of changing them), I just want to point 
>> out what is
>> required.
>
> Should decode. Meaning there's no change of semantics, just 
> where the facility is defined. -- Andrei

Having thought about it more, I think that is why we cannot put 
the range primitives for slices into object.d. Because that makes 
it impossible to define the primitives differently, so that no 
auto-decoding occurs. At the moment, auto-decoding isn't part of 
the language, it's just written in to the standard library. This 
would change that.