On Monday, 10 March 2014 at 14:42:18 UTC, Dicebot wrote:
> Yes. I have given up about this idea at some point as there seemed to be consensus that no breaking changes will be even considered for D2 and those that come from fixing bugs are not worth the fuss.

So at what point are we going to discuss these things
in the context of D-next?  These topics have us group
up and focus on compromises instead of ideals.  As was
said, D2 is at the 90% point.  It only has room left
for bug fixes.  I think we would make much more
productive use of our time and minds coming up with
ideas that actually have a chance of coming to
fruition, even if D3 ends up being half a decade away.

On 3/10/2014 6:47 AM, Dicebot wrote:
> (array literals that allocate, I will never forgive that).

It was done that way simply to get it up and running quickly. Having them not allocate is an optimization, it doesn't change the nature.

On 3/10/2014 7:35 PM, Yota wrote:
> On Monday, 10 March 2014 at 14:42:18 UTC, Dicebot wrote:
>> Yes. I have given up about this idea at some point as there seemed to
>> be consensus that no breaking changes will be even considered for D2
>> and those that come from fixing bugs are not worth the fuss.
>
> So at what point are we going to discuss these things
> in the context of D-next?

Not until (at least) the D2/Phobos implementations mature, the current issues get worked out, and the library/tool ecosystem grows and matures.

On Mon, 10 Mar 2014 19:59:07 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/10/2014 6:47 AM, Dicebot wrote:
>> (array literals that allocate, I will never forgive that).
>
> It was done that way simply to get it up and running quickly. Having them not allocate is an optimization, it doesn't change the nature.

I think you forget about this:

foo(int v, int w)
{
   auto x = [v, w];
}

Which cannot pre-allocate.

That said, I would not mind if this code broke and you had to use array(v, w) instead, for the sake of avoiding unnecessary allocations.

-Steve

On 3/10/14, 7:07 PM, Steven Schveighoffer wrote:
> On Mon, 10 Mar 2014 19:59:07 -0400, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On 3/10/2014 6:47 AM, Dicebot wrote:
>>> (array literals that allocate, I will never forgive that).
>>
>> It was done that way simply to get it up and running quickly. Having
>> them not allocate is an optimization, it doesn't change the nature.
>
> I think you forget about this:
>
> foo(int v, int w)
> {
>     auto x = [v, w];
> }
>
> Which cannot pre-allocate.

It actually can, seeing as x is a dead assignment :o).

> That said, I would not mind if this code broke and you had to use
> array(v, w) instead, for the sake of avoiding unnecessary allocations.

Fixing that:

int[] foo(int v, int w) { return [v, w]; }

This one would allocate. But analyses of varying complexity may eliminate a variety of allocation patterns.


Andrei

On Mon, 10 Mar 2014 22:56:22 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 3/10/14, 7:07 PM, Steven Schveighoffer wrote:
>> On Mon, 10 Mar 2014 19:59:07 -0400, Walter Bright
>> <newshound2@digitalmars.com> wrote:
>>
>>> On 3/10/2014 6:47 AM, Dicebot wrote:
>>>> (array literals that allocate, I will never forgive that).
>>>
>>> It was done that way simply to get it up and running quickly. Having
>>> them not allocate is an optimization, it doesn't change the nature.
>>
>> I think you forget about this:
>>
>> foo(int v, int w)
>> {
>>     auto x = [v, w];
>> }
>>
>> Which cannot pre-allocate.
>
> It actually can, seeing as x is a dead assignment :o).

Actually, it can't do anything, seeing as it's invalid code ;)

>> That said, I would not mind if this code broke and you had to use
>> array(v, w) instead, for the sake of avoiding unnecessary allocations.
>
> Fixing that:
>
> int[] foo(int v, int w) { return [v, w]; }
>
> This one would allocate. But analyses of varying complexity may eliminate a variety of allocation patterns.

I think you are missing what I'm saying, I don't want the allocation eliminated, but if we eliminate some allocations with [] and not others, it will be confusing. The path I'd always hoped we would go in was to make all array literals immutable, and make allocation of mutable arrays on the heap explicit.

Adding eliding of some allocations for optimization is good, but I (and I think possibly Dicebot) think all array literals should not allocate.

-Steve

On 3/10/14, 8:05 PM, Steven Schveighoffer wrote:
> I think you are missing what I'm saying, I don't want the allocation
> eliminated, but if we eliminate some allocations with [] and not others,
> it will be confusing. The path I'd always hoped we would go in was to
> make all array literals immutable, and make allocation of mutable arrays
> on the heap explicit.
>
> Adding eliding of some allocations for optimization is good, but I (and
> I think possibly Dicebot) think all array literals should not allocate.

I think so too. But that's irrelevant because arrays do allocate (at least behave as if they did) and that's how the cookie crumbles.

D is a wonderful language, and is getting better literally by day. There is a lot more in using it in new and interesting ways, than in brooding about its inevitable imperfections.


Andrei

On Sunday, 9 March 2014 at 21:38:06 UTC, Nick Sabalausky wrote:
> On 3/9/2014 7:47 AM, w0rp wrote:
>>
>> My knowledge of Unicode pretty much just comes from having
>> to deal with foreign language customers and discovering the problems
>> with the code unit abstraction most languages seem to use. (Java and
>> Python suffer from similar issues, but they don't really have algorithms
>> in the way that we do.)
>>
>
> Python 2 or 3 (out of curiosity)? If you're including Python3, then that somewhat surprises me as I thought greatly improved Unicode was one of the biggest reasons for the jump from 2 to 3. (Although it isn't *completely* surprising since, as we all know far too well here, fully correct Unicode is *not* easy.)

Late reply here. Python 3 is a lot better in terms of Unicode support than 2. The situation in Python 2 was this.

1. The default string type is 'str', an immutable array of bytes.
2. 'str' could be one of many encodings, including UTF-16, etc.
3. There is an extra 'unicode' type for when you want a Unicode string.
4. Python implicltly converts between the two, often in wrong ways, often causing exceptions to appear where you didn't expect them to.

In 3, this changed to...

1. The default string type is still named 'str', only now it's like the 'unicode' of olde.
2. 'bytes' is a new immutable array of bytes type like the Python 2 'str'.
3. Conversion between 'str' and 'bytes' is always explicit.

However, Python 3 works on a code point level, probably some code unit level in fact, and you don't see very many algorithms which take, say, combining characters into account. So Python suffers from similar issues.

On Friday, 7 March 2014 at 03:52:42 UTC, Walter Bright wrote:
>
> Ok, I have a plan. Each step will be separated by at least one version:
>
> 1. implement decode() as an algorithm for string types, so one can write:
>
>     string s;
>     s.decode.algorithm...
>
> suggest that people start doing that instead of:
>
>     s.algorithm...
>
> 2. Emit warning when people use std.array.front(s) with strings.
>
> 3. Deprecate std.array.front for strings.
>
> 4. Error for std.array.front for strings.
>
> 5. Implement new std.array.front for strings that doesn't decode.

What about this:

[as above]
1. implement decode() as an algorithm for string types, so one can write:

     string s;
     s.decode.algorithm...

 suggest that people start doing that instead of:

     s.algorithm...

[as above]
2. Emit warning when people use std.array.front(s) with strings.

3. Implement new std.array.front for strings that doesn't decode, but keep the old one either forever(ish) or until way into D3 (3.03).

4. Deprecate std.array.front for strings (see 3.)
5. Error for std.array.front for strings. (see 3)

I know that one of the rules of D is "warnings should eventually become errors", but there is nothing wrong with waiting longer than a few months before something is an error or removed from the library, especially if it would cause loads of code to break (my own too, I suppose). As long as users are aware of it, they can start to make the transition in their own code little by little. In this case they will make the transition rather sooner than later, because nobody wants to suffer constant performance penalties. So for this particular change I'd suggest to wait patiently until it can finally be deprecated. Is this feasible?

On Tuesday, 11 March 2014 at 02:07:19 UTC, Steven Schveighoffer wrote:
> On Mon, 10 Mar 2014 19:59:07 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 3/10/2014 6:47 AM, Dicebot wrote:
>>> (array literals that allocate, I will never forgive that).
>>
>> It was done that way simply to get it up and running quickly. Having them not allocate is an optimization, it doesn't change the nature.
>
> I think you forget about this:
>
> foo(int v, int w)
> {
>    auto x = [v, w];
> }
>
> Which cannot pre-allocate.

The array is small and does not escape.  It could be allocated on the stack as an optimization.