Georg Wrede wrote:
> John Demme wrote:
>> Walter Bright wrote:
>>
>>
>>> I think the title says it all.
>>
>>
>> Has anyone recommended that 0.163 should be labelled RC1?  I think this
>> would be fair- hopefully it would focus attention from language changes to
>> finding major bugs/flaws and the "Shop's closed- let's clean up and ship
>> it" mentality.  It would tell people who are maintaining libraries to
>> bother to update them to 0.163 so they will work with 1.0.
> 
> This sounds quite reasonable.

I agree. 0.163 seems like a solid feature base to build 1.0 libraries around. But I wonder how long Walter will be able to restrain himself from adding new features; I think he'd get bored after a dozen releases containing nothing but bug fixes. <g>

Walter Bright wrote:
> I think the title says it all.

I would consider non static structure initialization before going one dot oh.

The rest looks great, clear up any major bugs and ship it!

-DavidM

Don Clugston wrote:

> I agree. 0.163 seems like a solid feature base to build 1.0 libraries around. But I wonder how long Walter will be able to restrain himself from adding new features; I think he'd get bored after a dozen releases containing nothing but bug fixes. <g>

I think after 1.0 there'll be an expermental fork of DMD for toying with 2.0 stuff.

-- 
AKhropov

Chris Nicholson-Sauls wrote:
> 
> And I believe this is what is used in the new edition of C# for type inference, yes?

Yes, though 'auto' will be used for type inference in C++.  Personally, I'd prefer scoped destruction to use a keyword such as 'local' or 'scoped' than to change the keyword used for type inference.


Sean

Don Clugston wrote:
> Georg Wrede wrote:
>> John Demme wrote:
>>> Walter Bright wrote:
>>>
>>>
>>>> I think the title says it all.
>>>
>>>
>>> Has anyone recommended that 0.163 should be labelled RC1?  I think this
>>> would be fair- hopefully it would focus attention from language changes to
>>> finding major bugs/flaws and the "Shop's closed- let's clean up and ship
>>> it" mentality.  It would tell people who are maintaining libraries to
>>> bother to update them to 0.163 so they will work with 1.0.
>>
>> This sounds quite reasonable.
> 
> I agree. 0.163 seems like a solid feature base to build 1.0 libraries around. But I wonder how long Walter will be able to restrain himself from adding new features; I think he'd get bored after a dozen releases containing nothing but bug fixes. <g>

I'm actually hoping that one of the reasons for releasing 1.0 now is because Walter wants to get to work on 2.0 <g> (Not that 1.0 isn't good enough, just that it's fun to "play" :))

I'm curious - are there really any "show stopping" type bugs out there for v1.0? By show stopping I mean bugs that completely prevent a given design pattern allowed by the current language spec.

Thanks,

- Dave

Dave skrev:
> Don Clugston wrote:
>> Georg Wrede wrote:
>>> John Demme wrote:
>>>> Walter Bright wrote:
>>>>
>>>>
>>>>> I think the title says it all.
>>>>
>>>>
>>>> Has anyone recommended that 0.163 should be labelled RC1?  I think this
>>>> would be fair- hopefully it would focus attention from language changes to
>>>> finding major bugs/flaws and the "Shop's closed- let's clean up and ship
>>>> it" mentality.  It would tell people who are maintaining libraries to
>>>> bother to update them to 0.163 so they will work with 1.0.
>>>
>>> This sounds quite reasonable.
>>
>> I agree. 0.163 seems like a solid feature base to build 1.0 libraries around. But I wonder how long Walter will be able to restrain himself from adding new features; I think he'd get bored after a dozen releases containing nothing but bug fixes. <g>
> 
> I'm actually hoping that one of the reasons for releasing 1.0 now is because Walter wants to get to work on 2.0 <g> (Not that 1.0 isn't good enough, just that it's fun to "play" :))
> 
> I'm curious - are there really any "show stopping" type bugs out there for v1.0? By show stopping I mean bugs that completely prevent a given design pattern allowed by the current language spec.

I'd say the implicit function template instantiation limitations are somewhat show stopping:

1. IFTI doesn't work for member functions.
2. Partial specialization doesn't work with IFTI.
3. Partial template instantiation isn't allowed with IFTI.
4. More IFTI limitations...

Walter has acknowledged that number 2 is a bug. I don't know of any workaround for number 1. Those are all hampering library development, which IMHO would qualify as show stoppers for a 1.0 status.

Of course, the most important thing is to make clear which limitations are meant to remain and which are to be classified as bugs.

/Oskar

Dave wrote:
> Don Clugston wrote:
>> Georg Wrede wrote:
>>> John Demme wrote:
>>>> Walter Bright wrote:
>>>>
>>>>
>>>>> I think the title says it all.
>>>>
>>>>
>>>> Has anyone recommended that 0.163 should be labelled RC1?  I think this
>>>> would be fair- hopefully it would focus attention from language changes to
>>>> finding major bugs/flaws and the "Shop's closed- let's clean up and ship
>>>> it" mentality.  It would tell people who are maintaining libraries to
>>>> bother to update them to 0.163 so they will work with 1.0.
>>>
>>> This sounds quite reasonable.
>>
>> I agree. 0.163 seems like a solid feature base to build 1.0 libraries around. But I wonder how long Walter will be able to restrain himself from adding new features; I think he'd get bored after a dozen releases containing nothing but bug fixes. <g>
> 
> I'm actually hoping that one of the reasons for releasing 1.0 now is because Walter wants to get to work on 2.0 <g> (Not that 1.0 isn't good enough, just that it's fun to "play" :))
> 
> I'm curious - are there really any "show stopping" type bugs out there for v1.0? By show stopping I mean bugs that completely prevent a given design pattern allowed by the current language spec.

Shared library support on Linux? Although that's DMD only, its not a problem for GDC AFAIK.

Looking through Issuezilla, DStress and the Pending Peeves, most of the bugs seem to be pretty obscure. There are some serious ddoc bugs, but no stand-outs in the compiler itself.

Oskar's comments about IFTI are true, although I wouldn't classify the limitations as a bug. They have huge implications for library development -- but they'll all be backwards compatible improvements.

Don Clugston wrote:
> Oskar's comments about IFTI are true, although I wouldn't classify the limitations as a bug. They have huge implications for library development -- but they'll all be backwards compatible improvements.

That's true, so I'm not too concerned about them for 1.0.

There's also plenty of room for library development that doesn't need templates at all. I don't want to fall into the Boost mindset where even simple things are loaded up with impenetrable layers of templates.

Andrei Khropov wrote:
> Don Clugston wrote:
> 
> 
>>I agree. 0.163 seems like a solid feature base to build 1.0 libraries around.
>>But I wonder how long Walter will be able to restrain himself from adding new
>>features; I think he'd get bored after a dozen releases containing nothing
>>but bug fixes. <g>
> 
> 
> I think after 1.0 there'll be an expermental fork of DMD for toying with 2.0
> stuff.

Well, there _should_!

Andrei Khropov wrote:
> And what about double meaning of 'auto'?
> 
> It's a longstanding issue and changes could break lots of code, but I think it's
> a terrible design inconsistency.
> 
> And it also currently means that we cannot use type inference with auto classes
> (which is also inconsistensy by itself)
> 
> ------------------------------------------------
> import std.stdio;
> 
> auto class X
> {
> public:
>     int _i;
>         this(int i1)
>     {
>         _i = i1;
>     }
>         int i()
>     {
>         return _i;
>     }
>         ~this()
>     {
>       writefln("destructor i=",_i);     }
> }
> 
> void main()
> {
>     auto X x1 = new X(1);
>         //auto auto x2 = new X(2); // auto1.d(28): redundant storage class 'auto'
>         // auto x3 = new X(3); // auto1.d(30): variable auto1.main.x3 reference to
> auto class must be auto
>         writefln("x1.i=",x1.i);
>     //writefln("x2.i=",x2.i);
>     //writefln("x3.i=",x3.i);
> }
> ---------------------------------------------------
> 
> Some discussion was here: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/38443
> 
> (I personally vote for 'var' for type inference)

However I'm for a quick 1.0, I can't help but agreeing with this. (Sorry, Walter!)