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.
