July 24, 2006
clayasaurus wrote:
> Gregor Richards wrote:
> 
>> clayasaurus wrote:
>>
>>> Dave wrote:
>>>
>>>> Walter Bright wrote:
>>>>
>>>>> I think the title says it all.
>>>>
>>>>
>>>>
>>>> I say it's ready for 1.0.
>>>
>>>
>>>
>>> vote++
>>
>>
>> In my opinion it's unwise to make a point-oh release of anything immediately after major, sweeping changes.  A few months more time for people to submit major language change ideas before closing it up (which I presume 1.0 would imply) would be a good idea.
>>
>>  - Gregor Richards
> 
> 
> If we waited a few months after every release, we'd never have D 1.0.
> 
> Maybe Walter can label this as D 1.0 Release Candidate 1.
> 
> ~ Clay

Wait after every RELEASE?  NO!  Just make sure there are no changes clamoring at the gate to get in before releasing a point-oh.  Point-oh's shouldn't be considered as "just another release"!

 - Gregor Richards
July 24, 2006
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)

-- 
AKhropov
July 24, 2006
"Andrei Khropov" <andkhropov@nospam_mtu-net.ru> wrote in message news:ea14gh$dia$1@digitaldaemon.com...
>
> 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.
>
.............

> (I personally vote for 'var' for type inference)


You'd have my vote ....



July 24, 2006
Reiner Pope wrote:

> Not trying to be too argumentative here, but I obviously disagree with what you said, otherwise I wouldn't have said it in the first place. The problem is that the more *big* releases you make, the less interest people take in the language, so it's a good idea too catch their interest from the start. I disagree that "1.0" means first cut, because in many OSS projects (which D effectively is), version numbers don't get to 2.0 or beyond. IMHO it really means, "we've got a complete product now, you should have no problems with it."

I guess it depends on how one looks at these things.

Designing a library that works well takes time and, ideally, lots of real world experience with prototypes. It's hard to accumulate that experience, it seems to me, before the language has stablized. Requiring D v1.0 to be a stable language *and* to have an extensive library might take more time than would be good (although, honestly, I'm not that familiar with the extent of what's available right now in the way of D libraries). Long delays before a 1.0 release might turn some people off as well.

Peter
July 24, 2006
Dave wrote:

> IIRC, Walter has recently stated that D is already as stable as many compilers out there. We happen to have a highly visible bug list and regression tests that probably make things look worse than they really are _relative to other compilers_ who don't publish this stuff.

Just to clarify: in my original posting I was using the word "stable" to refer to the language specification and not the compiler itself. A library writer would prefer a stable language to design against over one that is perceived as being in a state of flux. Compiler bugs are a fact of life. Obviously the fewer bugs the better, but bugs can be worked around.

Peter
July 24, 2006
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)
> 

Agreed, and I've caught myself more than once starting to type this "auto auto" mess.  And I also agree with "var" as a good choice for doing this.  I'm already used to using "var" in other platforms, including PHP, ECMAScript, and my own Bovis language.

##### PHP
# class Foo {
#   var $someField = 42 ;
# }

##### ECMAScript
# var x = 27 ;

##### Bovis
# var 'Any $foo = 99 ; // the 'Any specifier is optional, of course

And I believe this is what is used in the new edition of C# for type inference, yes?  (I haven't touched C# since the 1.0 so someone let me know if I'm wrong.)  Precedence has been established for it.  It shouldn't be un-intuitive to many people.

-- Chris Nicholson-Sauls
July 24, 2006
Peter C. Chapin wrote:
> Reiner Pope wrote:
> 
>> Not trying to be too argumentative here, but I obviously disagree with what you said, otherwise I wouldn't have said it in the first place. The problem is that the more *big* releases you make, the less interest people take in the language, so it's a good idea too catch their interest from the start. I disagree that "1.0" means first cut, because in many OSS projects (which D effectively is), version numbers don't get to 2.0 or beyond. IMHO it really means, "we've got a complete product now, you should have no problems with it."
> 
> I guess it depends on how one looks at these things.
> 
> Designing a library that works well takes time and, ideally, lots of real world experience with prototypes. It's hard to accumulate that experience, it seems to me, before the language has stablized. Requiring D v1.0 to be a stable language *and* to have an extensive library might take more time than would be good (although, honestly, I'm not that familiar with the extent of what's available right now in the way of D libraries). Long delays before a 1.0 release might turn some people off as well.
> 
> Peter
OK, you and Dave have convinced me.
July 24, 2006
Lars Ivar Igesund wrote:
> Walter Bright wrote:
> 
>> I think the title says it all.
> 
> When immutability is achievable and protection attributes actually work in
> sane and consistent way for classes, inheritance and mixins (mixins are
> cool but a fairly raw feature).
> 
I'm inclined to agree on the topic of immutability. Although delaying 1.0 in order to find a solution is very disappointing, many people think that a good immutability system is important, and leaving one out of a 1.0 release makes that goal less achievable because it is almost certain to break some code.
July 24, 2006
Chris Nicholson-Sauls wrote:

> And I believe this is what is used in the new edition of C# for type inference, yes?
Yes. It'll be in C# 3.0

http://en.wikipedia.org/wiki/C_Sharp#C.23_3.0_new_language_features

One other thing there that I'm really fond of is LINQ.
I'm afraid it's impossible to do this with the current D means :-(.

-- 
AKhropov
July 24, 2006
Reiner Pope wrote:

> many people think that a good
> immutability system is important, and leaving one out of a 1.0 release makes
> that goal less achievable because it is almost certain to break some code.

Good point. I agree.

-- 
AKhropov