Robert Fraser wrote:
> Also, overload sets (great idea, but very much breaking).

I haven't used D2 much, but from what I've read on overload sets I can't see how they'd breaking (very much) stuff.
From what I understand, the "single overload set" case is identical to what happens in D1, and the cases with multiple ones are always an error in D1 (assuming a call to one of the overloads is attempted). The only case where the behavior would differ in the case of valid D1 code compiled as "D1 + overload sets" would be the result of something like is(typeof(foo(ARGS))) where "foo" consists of multiple overload sets, AFAICT. And I can't imagine that corner case to be "very much breaking" all by itself...

Robert Fraser wrote:
> Chris Wright wrote:
>> So you'd accept added keywords such as __traits, I take it? Though invariant would be a pretty controversial one to add.
> 
> Well, __traits is okay because it isn't commonly used as an identifier. But I'd prefer "macro" be changed to something like "__macro" in a backport (people might be using that as a variable name). Again, just personal opinion, that stuff doesn't matter too much.

It's another point of friction; ideally, anything that compiles in D1 will compile in D1.1. (Dunno yet how serious I am about forking, unless someone offers to help. In that case, I am quite serious.)

>> I think a fair number of people would be perfectly happy with a D2 branch minus const. I mean, what else was added that's not to love? Besides instability, that is. But the only thing preventing people from using most of these libraries with dmd2.014 is probably const.
> 
> IMO, pure and nothrow, too. I think it's a good idea but it requires too much library support (i.e. there's no way to write a standard lib that would work well under D1.0 and D1.1 if the latter had pure and nothrow). Also, overload sets (great idea, but very much breaking).

Pure and nothrow aren't implemented yet, I think, so it'd be easy to exclude them.

I agree with Fritz's assessment on overload sets, unless you can come up with a sample of code that overload sets breaks.

Chris Wright wrote:
> I agree with Fritz's assessment on overload sets, [...]

Thanks, but my name is Frits...

Frits van Bommel wrote:
> Chris Wright wrote:
>> I agree with Fritz's assessment on overload sets, [...]
> 
> Thanks, but my name is Frits...

Sorry, I've been reading a book where the main character's name is Fitz (the Farseer trilogy by Robin Hobb), so I'm lucky that I remembered the R. I meant to check the spelling, but I got lazy.

Chris Wright wrote:
> Bill Baxter wrote:
>> Chris Wright wrote:
>>> Robert Fraser wrote:
>>>> Sean Kelly wrote:
>>>>> What worries me is that long
>>>>> asked-for bug fixes like this may be left out of DMD 1.0 as a way to "encourage" people to move to D 2.0.  If that happens, I'm out.
>>>>
>>>> Indeed that's a fear I have as well. D 1.0 has never been fully stable (look at the ".init" change that happened after 2.0 was out... that broke a lot of code). So it seems rather arbitrary that a bug fix like this (reported as bug, not an enhancement, before 2.0 was on the horizon) would only make it to the 2.0 branch.
>>>
>>> A lot of people have been annoyed by a lot of these changes. Unfortunately, nobody (and that includes the lack of me) has gotten off their butts to release a DMD 1.1.x branch.
>>
>> When you say "nobody" are you suggesting that the D community should create a 1.1 branch and release it whether Walter wants it or not?
> 
> I am. There seems to be demand for it. And if there were such a branch, Walter could even stop maintaining the 1.x branch because bugfixes from the 2.x branch would get ported to the 1.1 branch.
> 
> This isn't ideal for the community, perhaps. If enough people were involved, however, Walter would just be working on an experimental branch, and the community would handle bugfixes.
> 
>> --bb

I've wanted a D 1.1 for a long time. When LLVMDC gets more stable (by that I mean to a point where it can compete with DMD), I could be interested in starting such a fork.

Walter Bright wrote:
> davidl wrote:
>> Added -lib switch to generate library files. Also causes multiple object files to be generated from one source module. <-- what does this exactly mean
>>
>> We need more docs on this.
> 
> http://www.digitalmars.com/d/2.0/dmd-windows.html#library

There, where you say "and existing object file bar.obj", don't you mean "abc.obj" instead?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bill Baxter wrote:
> Walter Bright wrote:
>> http://www.digitalmars.com/d/1.0/changelog.html
>> http://ftp.digitalmars.com/dmd.1.030.zip
>>
>> http://www.digitalmars.com/d/2.0/changelog.html
>> http://ftp.digitalmars.com/dmd.2.014.zip
> 
> Any chance we'll be getting a backport of the fix to bug 493 in DMD 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]
> 
> --bb

Hum, nice, I didn't know that was possible. I guess I didn't see it since no spec change occurred because of that fix (although it should?).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D