I suppose I can tell you know, D is an elaborate april fools joke, and was never going to be a real product!  All development up to now was to create the "greatest april fools joke of 2012", started by Walter 12 years ago!


OK, we can all stop developing now.  Later on, we can all look back on the past 5 or so years we spent constructing this elaborate hoax, and laugh.


-Steve




>________________________________
> From: Nick Sabalausky <bus_dmdbeta@semitwist.com>
>To: Discuss the dmd beta releases for D <dmd-beta@puremagic.com>
>Sent: Thursday, April 5, 2012 7:39 AM
>Subject: Re: [dmd-beta] D 1.074 and 2.059 betas
> 
>Might also consider bumping the date on the changelog to (closer to) whenever it's actually ready: If only because seeing "Released on April 1" probably doesn't instill a whole lot of confidence... ;)
>_______________________________________________
>dmd-beta mailing list
>dmd-beta@puremagic.com
>http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
>

From: "Nick Sabalausky" <bus_dmdbeta@semitwist.com>
> Was something changed with struct opCmp, or its signature, or "const" params? Because I'm getting some "wrong argument type" errors comparing some structs that use opCmp. I'll try to dig further into it and get a test case...
>


Regression(2.059 Beta): struct opEquals broken
http://d.puremagic.com/issues/show_bug.cgi?id=7833

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

From: "Nick Sabalausky" <bus_dmdbeta@semitwist.com>
> From: "Nick Sabalausky" <bus_dmdbeta@semitwist.com>
>> Was something changed with struct opCmp, or its signature, or "const" params? Because I'm getting some "wrong argument type" errors comparing some structs that use opCmp. I'll try to dig further into it and get a test case...
>>
>
>
> Regression(2.059 Beta): struct opEquals broken
> http://d.puremagic.com/issues/show_bug.cgi?id=7833
>

Ok, a reply in there mentioned that's not actually a bug. But, the changelog *really* should state prominently under "changed features" that:

1. Struct literals are no longer lvalues.

and

2. Things like opCmp/opEquals/etc in a struct now need an overload with non-const non-ref params in order to continue working with struct literals.

Maybe I'm biased since I ran head-first into it, but I'm betting that'll confuse the crap out of many people if it's not clearly mentioned under "changed features".

So I've renamed the issue:

[2.059 Beta] Changelog should clearly mention struct literal/opCmp/opEquals changes
http://d.puremagic.com/issues/show_bug.cgi?id=7833

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Regression(2.059 beta): Informational warning fails to produce executable
http://d.puremagic.com/issues/show_bug.cgi?id=7843

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

From: "Nick Sabalausky" <bus_dmdbeta@semitwist.com>
> From: "Nick Sabalausky" <bus_dmdbeta@semitwist.com>
>> From: "Nick Sabalausky" <bus_dmdbeta@semitwist.com>
>>> Was something changed with struct opCmp, or its signature, or "const" params? Because I'm getting some "wrong argument type" errors comparing some structs that use opCmp. I'll try to dig further into it and get a test case...
>>>
>>
>>
>> Regression(2.059 Beta): struct opEquals broken
>> http://d.puremagic.com/issues/show_bug.cgi?id=7833
>>
>
> Ok, a reply in there mentioned that's not actually a bug. But, the changelog *really* should state prominently under "changed features" that:
>
> 1. Struct literals are no longer lvalues.
>
> and
>
> 2. Things like opCmp/opEquals/etc in a struct now need an overload with non-const non-ref params in order to continue working with struct literals.
>
> Maybe I'm biased since I ran head-first into it, but I'm betting that'll confuse the crap out of many people if it's not clearly mentioned under "changed features".
>
> So I've renamed the issue:
>
> [2.059 Beta] Changelog should clearly mention struct literal/opCmp/opEquals changes
> http://d.puremagic.com/issues/show_bug.cgi?id=7833
>

See, now here's a problem though:

I add a non-ref non-const overload to those functions to make them work with struct literals on 2.059, and it works. But then 2.058 bitches it doesn't know which overload to use. I could do a static if on the compiler version, but that's DMD-specific - what about LDC and GDC?

I'm not necessarily saying that struct literals should be lvalues, but how am I supposed to reasonably make a program work on both 2.058 and 2.059?

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Friday, April 06, 2012 03:10:15 Nick Sabalausky wrote:
> I'm not necessarily saying that struct literals should be lvalues, but how am I supposed to reasonably make a program work on both 2.058 and 2.059?

You don't. It's a breaking change. The same will likely happen once Object becomes const-correct. While dmd and the language are far more stable than they used to be, breaking changes do occur upon occasion, making it so that new code cannot be compiled on older versions of the compiler or vice versa.

I suppose that you could use a version block and use a specific version for 2.058 if you really wanted to be able to compile it on both, but since it's a breaking change, it's not going to "just work."

However, why would you really want to be able to build with 2.058 once 2.059 is out? Granted, in the long run, breaking changes should become very uncommon such that it doesn't really matter which version of the compiler you're using for most things, but still, I don't see why you can't just say that the latest compiler is required to use your code if you're posting it somewhere.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

From: "Jonathan M Davis" <jmdavisProg@gmx.com>
>
> However, why would you really want to be able to build with 2.058 once 2.059
> is out? Granted, in the long run, breaking changes should become very uncommon
> such that it doesn't really matter which version of the compiler you're using
> for most things, but still, I don't see why you can't just say that the latest
> compiler is required to use your code if you're posting it somewhere.
>

Because libraries that only work with one compiler version are annoying for their users.

Regardless, I've realized I can probably just detect it thanks to the brilliant magic that is __traits(compiles,...)  (Take that, "autoconf"! ;))

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Friday, April 06, 2012 03:38:50 Nick Sabalausky wrote:
> From: "Jonathan M Davis" <jmdavisProg@gmx.com>
> 
> > However, why would you really want to be able to build with 2.058 once
> > 2.059
> > is out? Granted, in the long run, breaking changes should become very
> > uncommon
> > such that it doesn't really matter which version of the compiler you're
> > using
> > for most things, but still, I don't see why you can't just say that the
> > latest
> > compiler is required to use your code if you're posting it somewhere.
> 
> Because libraries that only work with one compiler version are annoying for their users.

Understandable, but dmd is still early enough in its development that you can't rely on everything working the same from release to release (though it's getting better; changes are now mostly due to bug fixes rather than drastic feature changes or regressions - particularly since we're trying harder to fix all new regressions before releasing), and in general, you really should be using the latest compiler. In the long run, that should change, but we're not quite there yet.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 4/6/12, Nick Sabalausky <bus_dmdbeta@semitwist.com> wrote:
> Regardless, I've realized I can probably just detect it thanks to the
> brilliant magic that is __traits(compiles,...)  (Take that, "autoconf"! ;))

Yeah traits is great. Btw, a side-tip to library authors (not aimed at Nick): Please don't drown compilation errors with __traits(compiles) if you're instantiating a template from user-code, because it makes it hard for the user to figure out that a template was never instantiated.

E.g. msgpack-d allows you to define a custom serialization function
that it will invoke if found in a struct/class. But this function has
to be a template of the form:
void toMsgpack(Packer)(ref Packer packer) const { }

The problem is, if there's invalid code in the template the compiler
won't verify it until the template is instantiated. Msgpack itself
instantiates it, but it first does a check with __traits(compiles),
and if the template doesn't instantiate it just skips calling the
function altogether. So then the user has to wonder why his function
was never called.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Fixed.

On 4/4/2012 1:44 PM, Sönke Ludwig wrote:
> I've hit another regression:
>
> struct Test {
>      static immutable c = Test();
>      static if( true ){}
> }
>
> when compiled with no options gives
>
> Error: static if conditional cannot be at global scope
>
> Changing to
>
> struct Test {
>      static immutable Test c = Test();
>      static if( true ){}
> }
>
> does not trigger the error.
>
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta