On Thu, 23 May 2013 23:38:32 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
>> This is one change where ALL code broken by this change
>> is fixable with a simple solution, and at some point, people will have to deal
>> with this.
>
> Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the warning.

If they aren't in the mood to change their code, they don't have to upgrade to the latest compiler.

-Steve

On 5/23/2013 8:53 PM, Steven Schveighoffer wrote:
> On Thu, 23 May 2013 23:38:32 -0400, Walter Bright <newshound2@digitalmars.com>
> wrote:
>
>> On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
>>> This is one change where ALL code broken by this change
>>> is fixable with a simple solution, and at some point, people will have to deal
>>> with this.
>>
>> Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the warning.
>
> If they aren't in the mood to change their code, they don't have to upgrade to
> the latest compiler.

Q: Why do we bother with the whole warning and deprecation thing anyway?

A: Because forcing people to conform to our schedule with no warning is a bit presumptuous. Someone writing a library, for example, has to be up to date, and anyone using that library, for another, has to deal with it if it fails to compile. If your code is built from multiple blobs from various places, it is unreasonable to expect them to all instantly and simultaneously upgrade.


I'm a little startled by these responses, especially considering that just yesterday we had a long thread about lack of stability and breaking changes.

On 5/23/2013 11:17 PM, Walter Bright wrote:
> On 5/23/2013 8:53 PM, Steven Schveighoffer wrote:
>> On Thu, 23 May 2013 23:38:32 -0400, Walter Bright
>> <newshound2@digitalmars.com>
>> wrote:
>>
>>> On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
>>>> This is one change where ALL code broken by this change
>>>> is fixable with a simple solution, and at some point, people will
>>>> have to deal
>>>> with this.
>>>
>>> Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the
>>> warning.
>>
>> If they aren't in the mood to change their code, they don't have to
>> upgrade to
>> the latest compiler.
>
> Q: Why do we bother with the whole warning and deprecation thing anyway?
>
> A: Because forcing people to conform to our schedule with no warning is
> a bit presumptuous. Someone writing a library, for example, has to be up
> to date, and anyone using that library, for another, has to deal with it
> if it fails to compile. If your code is built from multiple blobs from
> various places, it is unreasonable to expect them to all instantly and
> simultaneously upgrade.
>

I would argue the language should be designed with the ability to easily add keywords without breaking things.  I would expect a simple implementation to be that each source file needs to be marked up with a version of the compiler it is designed for, and the compiler could tell you that A) you are using what is now a keywords B) compile the code correctly anyway.

The lack of this kind of feature is why c++11's new null type is named nullptr, and not null, and why pure virtuals are declared with '=0' instead of a keyword.  Arguably c++11's range based for loops are also designed with this constraint (avoid adding a keyword), but is a not ugly like =0 pure virtuals :)

On 2013-05-24 02:01, Walter Bright wrote:

> Don has an excellent point. His case is bolstered by this causing Tango2
> to fail to compile with error messages that have no obvious relationship
> with this change.
>
> Worse, as Don points out, this can result in silent breakage. Not
> everyone writes code that is 100% tested, and shipping code that no
> longer works would make someone justifiably very upset.
>
> The -transition=field detects such cases, but the user will not
> necessarily know to run it.
>
> So, I agree with Don. As it is, this is unacceptable, despite my
> agreement that it does make the language better. Therefore, I propose
> the following addition of a warning:
>
> ------------------------------
>     const int q = 5;
>
> Warning: const field with initializer should be static or enum.
> ------------------------------
>
> Over time, this can be upgraded to a deprecation and then an error.
>
> After a suitably long period of time as an error, then we can allow it
> with the new behavior.

I like that idea. It doesn't suddenly breaking existing code. Gives a bit of transition time.

-- 
/Jacob Carlborg

On 23 May 2013 22:46, Walter Bright <newshound2@digitalmars.com> wrote:
> On 5/23/2013 4:07 AM, Iain Buclaw wrote:
>>
>> On 21 May 2013 21:36, Walter Bright <newshound2@digitalmars.com> wrote:
>>>
>>>
>>> Join the dmd beta mailing list to keep up with the betas. This one is
>>> pretty
>>> much good to go, unless something disastrous crops up.
>>>
>>> http://ftp.digitalmars.com/dmd2beta.zip
>>>
>>> Remaining regressions:
>>>
>>>
>>> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
>>
>>
>>
>> Is this zip based off the 2.063 branch?
>
>
> Yes, that's the whole point!
>
>
>> Seems to be cherry picking the odd commit over the last couple of days....
>
>
> It's cherry picking the regression fixes.
>

Not at all a problem, just means I'll be updating to 2.063 + some extra patches that didn't make it into the release this time around.

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 23 May 2013 at 22:25:18 UTC, Andrej Mitrovic wrote:
> On 5/23/13, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
>> 2) it doesn't know which file is the "main"
>> program file (the file which must be present for the test script
>> to succeed), if there is one.
>
> Does https://github.com/D-Programming-Language/dmd/pull/1732 help? It
> was merged a while back.

DustMite would need to dissect the user's command line and inject the switch. With probably the same amount of success, it'd be easier to heuristically detect a filename in the supplied command line, but that's something I'd like to avoid. Timothee continued the discussion in a DustMite issue: https://github.com/CyberShadow/DustMite/issues/13

On Thursday, 23 May 2013 at 16:01:56 UTC, Don wrote:
> That's better, but it's still not a convincing example.
>
> I don't see why you cannot remove the intializer, and write:
>
> this(bool IPv6)
> {
>     if (!IPv6)
>       etherType = 0x0800;
>     else
>       etherType = 0x86DD;
>   ...
> }

Because then you will have an invalid default-initialized state. For example, in my case static array of Packets can be declared and I am guaranteed to have a properly initialized packet templates there (constructor can't be used obviously). Now after some thinking I favor template-based approach specifically for this task but general principle should be clear.

> That only leaves the case where you are bypassing the constructor.

Not "by-passing", more like "not getting to". That it is one of subtle and incredibly awesome D features - T.init

> If you have a constructor, but have just used Packet.init, the object is not constructed properly. I cannot see the value in having etherType initialized and everything else not.

I have not mentioned other fields but they are expected to be initialized too, thanks to CTFE (don't know how it inter-operates with unions in current DMD though). So Packet.init here becomes _completely constructed_ Packet with defaults computed at compile-time.

I like it. A lot, probably.

When semantics of something does change it makes a lot sense to decouple deprecation of old behavior and introduction of new. I may even say it is worth using as a default approach for a semantics change in similar cases ;)

On Friday, 24 May 2013 at 00:01:20 UTC, Walter Bright wrote:
> On 5/23/2013 2:05 AM, Don wrote:
>> NO NO NO NO. I am violently opposed to this release.
>>
>> This beta contains the worst language misfeature of all time. It's silently
>> snuck in under the guise of a bugfix.
>
> Don has an excellent point. His case is bolstered by this causing Tango2 to fail to compile with error messages that have no obvious relationship with this change.
>
> Worse, as Don points out, this can result in silent breakage. Not everyone writes code that is 100% tested, and shipping code that no longer works would make someone justifiably very upset.
>
> The -transition=field detects such cases, but the user will not necessarily know to run it.
>
> So, I agree with Don. As it is, this is unacceptable, despite my agreement that it does make the language better. Therefore, I propose the following addition of a warning:
>
> ------------------------------
>    const int q = 5;
>
> Warning: const field with initializer should be static or enum.
> ------------------------------
>
> Over time, this can be upgraded to a deprecation and then an error.
>
> After a suitably long period of time as an error, then we can allow it with the new behavior.

On Thu, 23 May 2013 19:52:14 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 5/23/13 2:08 PM, Marco Leise wrote:
>> Am Thu, 23 May 2013 13:06:44 -0400
>> schrieb Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>:
>>
>>> TDPL 8.4 discusses a raw/cooked model of construction. The same
>>> principle should apply to const/immutable member construction: you get
>>> to cook the field, but you can't taste it while raw.
>>
>> You are not making friends with Japanese D users.
>
> Good one! And incidentally I love sashimi :o). Well let me amend it: if your plan is to cook it, don't taste it before.

mmm cookie dough/cake batter. :p

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 05/24/13 02:33, Steven Schveighoffer wrote:
> On Thu, 23 May 2013 19:03:25 -0400, Artur Skawina <art.08.09@gmail.com> wrote:
> 
>> On 05/23/13 23:06, Steven Schveighoffer wrote:
> 
>>> compiles:
>>>
>>> struct S
>>> {
>>>    const int x;
>>>    this(int n)
>>>    {
>>>     x = n;
>>>    }
>>> }
>>
>> It's the 'const int x = 42;' case we're talking about. *That* one does not compile and doesn't need to. It /could/, but I see no reason to allow this;
> 
> My example is essentially:
> 
> const int x = 0;

Actually

   const x = int.init;

but these *are* different, and, again - currently the compiler will not allow
mutation - if you add that "= 0" part to your example above it will no longer
compile.
Hence, you are arguing for a change in behavior. And the arguments for that
are extremely weak. The goal should be to allow const initialization to happen
exactly once. The fact some compiler is currently unable to enforce the rules [1]
is not a good argument - the situation will improve eventually. And reversing
such a change later would be harder, as it would break code that started to
rely on the new rules.

artur

[1] /a/ set of rules, even if different from the ones I'm talking about.
    That's a broader topic. In this specific case nothing /needs/ to change,
    so adjusting the definition (if there even is any) is an option.