On Thursday, 30 April 2015 at 16:49:59 UTC, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message news:mhtggg$26b5$1@digitalmars.com...
>
>> I think we need to stop here. I'll make the PR today for reverting this language change. We can't handle D like a semester science project, because for as long as we do we won't have credibility.
>
>> This trickle of teeny-bit breaking changes for the sake of touted benefits must stop.
>
> This breaking change prevents hard-to-find bugs.  The fact that you needed to make trivial changes to 39 places in std.allocator doesn't negate this.

I can second this. The code is often not test in an apropriate manner.

Let's say you have some code that goes as:

auto foo(T[] ts) {
    if (ts) {
        // ...
    } else {
        // ...
    }
}

Now test :

unitest {
    assert(foo([1, 2, 3]) == ...);
    assert(foo([]) == ...);
}

All tests passes, the code looks correct, but in fact it is going to break when foo is called with a drained range, or some slicing tat happen to have 0 elements.

That makes for very hard to find bugs.

The current behavior is also inconsistent with general slice behavior (which distinguish between identity and value).

People are not making stuff up here. The current behavior is bug prone AND inconsistent. And yes, I'm working on SDC's GC, so I'm aware that there is code that specifically care about the address. This is what the is operator is for.

On Thursday, 30 April 2015 at 17:10:23 UTC, Jeremy Powers wrote:
> On Thu, Apr 30, 2015 at 8:08 AM, Andrei Alexandrescu via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>>
>> This trickle of teeny-bit breaking changes for the sake of touted benefits
>> must stop.
>>
>>
> This is how you improve the language.

Only if you ignore the costs of the change...

On Thursday, 30 April 2015 at 18:04:18 UTC, Vladimir Panteleev wrote:
> On Thursday, 30 April 2015 at 17:10:23 UTC, Jeremy Powers wrote:
>> On Thu, Apr 30, 2015 at 8:08 AM, Andrei Alexandrescu via Digitalmars-d <
>> digitalmars-d@puremagic.com> wrote:
>>
>>>
>>> This trickle of teeny-bit breaking changes for the sake of touted benefits
>>> must stop.
>>>
>>>
>> This is how you improve the language.
>
> Only if you ignore the costs of the change...

This one is quite straightforward. Dfix could probably handle it.

What about less intrusive change as a compromise?

I'm the C# guy and they solve these problems just with warnings. Each warning has some ID and compiler spits it out with the description of a problem itself.

Developers than have 4 ways to handle it:
1) ignore it and live with the warning
2) change the code to be correct
3) disable this exact warning type for a whole project
4) disable this exact warning in source file at the place of the warning itself

I think that similar approach would be helpful here.
Say we have an Andrei's allocator code which he knows that is correct. But spits out a lot of false positive warnings. So at the module header he just adds something like:

pragma(disablewarn, 123);

and don't care about it further.

So personally I wouldn't necessarily deprecate current behaviour with actual codebreak, but just spit out warning about possible error which can be easily taken care of and still can be pretty useful to find possible bugs.
Actually that should be major usage for warnings - notify developer that something is potentially wrong.

More about C# pragmas for warning handling: https://msdn.microsoft.com/en-us/library/441722ys.aspx

On Thursday, 30 April 2015 at 18:07:12 UTC, deadalnix wrote:
> This one is quite straightforward. Dfix could probably handle it.

I'd have to rewrite dfix on top of SDC to get this working. dfix can only work at the lexical and AST level at the moment. As soon as you need information like "Is this a dynamic array?" you need a compiler.

I could try using DCD's "suhmantick analisyss"[1] code to try to get this to work, but it wouldn't work correctly in a lot of cases.

[1] it's really dumb, but works well enough for an auto-complete engine

On Thursday, 30 April 2015 at 21:58:17 UTC, Brian Schott wrote:
> On Thursday, 30 April 2015 at 18:07:12 UTC, deadalnix wrote:
>> This one is quite straightforward. Dfix could probably handle it.
>
> I'd have to rewrite dfix on top of SDC to get this working. dfix can only work at the lexical and AST level at the moment. As soon as you need information like "Is this a dynamic array?" you need a compiler.
>
> I could try using DCD's "suhmantick analisyss"[1] code to try to get this to work, but it wouldn't work correctly in a lot of cases.
>
> [1] it's really dumb, but works well enough for an auto-complete engine

I'm sure that with "suhmantick analisyss" one can get a good cunk of the tests (not all, but something large enough). This paired with making the thing a warning rather than an error, should provide an easy transition path.

On Thursday, 30 April 2015 at 15:08:00 UTC, Andrei Alexandrescu wrote:
> On 4/30/15 4:46 AM, Daniel Murphy wrote:
>> "Vladimir Panteleev"  wrote in message
>> news:ajrysqkjmlqjlmkipboz@forum.dlang.org...
>>
>>> On Wednesday, 29 April 2015 at 19:15:46 UTC, Jonathan M Davis
>>> wrote:
>>> > but std.allocator is definitely not your average code
>>>
>>> OK, I'm tired of hearing this argument.
>>
>> It's valid though.
>
> I think we need to stop here. I'll make the PR today for reverting this language change. We can't handle D like a semester science project, because for as long as we do we won't have credibility.
>
> This trickle of teeny-bit breaking changes for the sake of touted benefits must stop.
>
> In the future please do not make breaking changes without my and Walter's approval.
>
>
> Thanks,
>
> Andrei

OK so, please revert this one:
https://github.com/D-Programming-Language/dmd/commit/2869ee9c1fb64f08b51d8d07ce72701dda4a6fae

and this one:
http://forum.dlang.org/thread/ibupwrwsgjvrjwabhmjd@forum.dlang.org

On Thursday, 30 April 2015 at 23:12:18 UTC, Daniel Kozak wrote:
> OK so, please revert this one:
> https://github.com/D-Programming-Language/dmd/commit/2869ee9c1fb64f08b51d8d07ce72701dda4a6fae
>


WAT ?

> and this one:
> http://forum.dlang.org/thread/ibupwrwsgjvrjwabhmjd@forum.dlang.org

I'm not sure I get the details of that one, would you mind to sum up the crux of the issue ?

"Andrei Alexandrescu"  wrote in message news:mhto1k$2dk0$1@digitalmars.com...

> Nothing negates that. It's a judgment call. Please let's stop here. Thanks. -- Andrei

Please stop trying to undo this improvement.  Just fix your code and move on.
Thanks. 

On Friday, 1 May 2015 at 01:12:08 UTC, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message news:mhto1k$2dk0$1@digitalmars.com...
>
>> Nothing negates that. It's a judgment call. Please let's stop here. Thanks. -- Andrei
>
> Please stop trying to undo this improvement.  Just fix your code and move on.
> Thanks.

There is probably a better way to introduce the change, that would facilitate the transition but I agree with the feeling. std.alocator is probably one of the only piece of code where this behavior is justified.