On Thu, 30 Apr 2015 20:27:01 +0000, TC wrote:

> pragma(disablewarn, 123);

please, no! nothing in source code should be able to disable warning -- except fixing the code. and such pragma simply ugly.

On Fri, 01 May 2015 11:12:12 +1000, 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.

D is not C++ enough, it needs more legacy warts. after all, the only thing that shows language maturity is how much legacy it accumulated.

On Friday, 1 May 2015 at 02:16:01 UTC, deadalnix wrote:
> 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.

I guess my earlier post got buried?

http://forum.dlang.org/post/ajrysqkjmlqjlmkipboz@forum.dlang.org

On Friday, 1 May 2015 at 05:53:36 UTC, Vladimir Panteleev wrote:
> On Friday, 1 May 2015 at 02:16:01 UTC, deadalnix wrote:
>> 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.
>
> I guess my earlier post got buried?
>
> http://forum.dlang.org/post/ajrysqkjmlqjlmkipboz@forum.dlang.org

Nothing in there tells us how much of these are actually justified and how much are bugs.

On Friday, 1 May 2015 at 06:02:15 UTC, deadalnix wrote:
> On Friday, 1 May 2015 at 05:53:36 UTC, Vladimir Panteleev wrote:
>> I guess my earlier post got buried?
>>
>> http://forum.dlang.org/post/ajrysqkjmlqjlmkipboz@forum.dlang.org
>
> Nothing in there tells us how much of these are actually justified and how much are bugs.

And that's your argument?

Consider:

1. I make very heavy use of array-to-bool conversions in my code;
2. To the best of my memory, I've NEVER had a bug due to incorrect array-to-bool conversions.

Honestly, pragmatically speaking, I think it would be easier for me to start maintaining my forked compiler than to "fix" all those warnings, plus the rather long tail of all the other D projects I've written over the years that I'm going to have to maintain sooner or later.

On 4/30/15 6:12 PM, 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.

After we have discussed this matter extensively Walter and I decided to move forward and undo this language change.

It's a judgment call. The advantages and disadvantages of this have been discussed extensively. We are accountable for decisions like this, and we must make the decisions we believe are right. That said, making a decision when there are strong feelings and opinions on both sides is always difficult.

We would really like to find consensus, but failing that, request your indulgence.

Please review: https://github.com/D-Programming-Language/dmd/pull/4623


Thanks,

Andrei

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

How about parsing DMD's output (with -vcolumns)?

On Friday, 1 May 2015 at 07:15:07 UTC, Vladimir Panteleev wrote:
> 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
>
> How about parsing DMD's output (with -vcolumns)?

Erm, never mind. I forgot this is all assuming the compiler
change is going away.

On Fri, 01 May 2015 00:12:53 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> 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 ?

struct S {
    immutable A = 5;
    int x;
}

int main() {

    S s;
    assert(s.sizeof == s.x.sizeof);
    assert(s.sizeof == s.x.sizeof + s.A.sizeof);
    return 0;
}

before 2.067:
core.exception.AssertError@test.d(12): Assertion failure

after 2.067:
core.exception.AssertError@test.d(11): Assertion failure



I do not want to change any of the issue above, I just do not understand why some breaking changes are OK, and some other are not so ok.

On Friday, 1 May 2015 at 08:40:25 UTC, Daniel Kozak wrote:
>
> <snip>
>
> I just do not understand why
> some breaking changes are OK, and some other are not so ok.
>

+1.... but, again, I'm hopeless that W+A will understand the break-my-code spirit...

/P