View mode: basic / threaded / horizontal-split · Log in · Help
July 22, 2006
Re: Is D 0.163 D 1.0?
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).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
July 22, 2006
Re: Is D 0.163 D 1.0?
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 fully agree with this. Java people are going to be appalled at the 
lack of consistency in the protection system. D is so elegant/consistent 
in everything else, why not protection?


-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
July 22, 2006
Re: Is D 0.163 D 1.0?
Brad Roberts schrieb am 2006-07-22:
> Walter Bright wrote:
>> I think the title says it all.

> Secondary to dmd and the 1.0ness of it, the 
> docs have some gaps that have been pointed out (though not a whole lot 
> of filed (thus trackable) about the website).  The abi is an example 
> that comes to mind.

In addition to the "TBD"s, float's "[blah, blah, blah]" comes to mind.

> From a functionality standpoint things are about ready, it's time for 
> the weeks of polishing.

As for polishing:
> dmd: expression.c:5733: virtual Expression* MinAssignExp::semantic(Scope*): Assertion `e2->type->isfloating()' failed.
> dmd: expression.c:725: virtual void Expression::toMangleBuffer(OutBuffer*): Assertion `0' failed.
> dmd: func.c:475: virtual void FuncDeclaration::semantic3(Scope*): Assertion `0' failed.
> dmd: mtype.c:536: virtual Expression* Type::getProperty(Loc, Identifier*): Assertion `deco' failed.
> dmd: template.c:2168: TemplateDeclaration* TemplateInstance::findTemplateDeclaration(Scope*): Assertion `s->parent' failed.
> dmd: tocsym.c:143: virtual Symbol* VarDeclaration::toSymbol(): Assertion `!needThis()' failed.
> dmd: toobj.c:194: virtual void ClassDeclaration::toObjFile(): Assertion `!scope' failed.
> Internal error: ../ztc/cgcod.c 1680
> Internal error: ../ztc/cgcod.c 175
> Internal error: ../ztc/cgcod.c 562
> Internal error: ../ztc/cod1.c 1656
> Internal error: ../ztc/type.c 308

http://dstress.kuehne.cn/polishing/dmd-internal.txt lists the triggering
command line followed be the error messages for "run" and "compile" tests.

Thomas
July 22, 2006
Re: Is D 0.163 D 1.0?
Walter Bright wrote:
> I think the title says it all.

I say it's ready for 1.0.
July 22, 2006
Re: Is D 0.163 D 1.0?
Please put some sort of mock pinning in 1.0 so it's possible to write 
code compatible for 2.0 :( (see other thread)
July 22, 2006
Re: Is D 0.163 D 1.0?
Dave wrote:
> Walter Bright wrote:
>> I think the title says it all.
> 
> I say it's ready for 1.0.

vote++
July 23, 2006
Re: Is D 0.163 D 1.0?
Walter Bright wrote:
> I think the title says it all.

Things I think should be defined by 1.0:
- How version numbers will be used;
- How to classify a compiler as D 1.0-compliant (ABI specs).

The first one is simple, and I have a suggestion: Use a 3-piece version
number schema, this way:

 1.0.0 -> D Language Spec 1.0, first compiler version

 1.x.(y++) -> Compiler fixes, without changes to D lang spec. Any code
written to any 1.x.y version should be acceptable to any other 1.x.z
version of the compiler, as long as it is the same x. Of course, ABI
should also not change.

 1.(x++).0 -> When changes are made to the lang spec, in a backwards
compatible way. Any code written to a 1.x.y version should be still
valid for 1.(x+1).0, or any other 1.z.0 version, as long as z >= x. ABI
should not change.

 (w++).0.0 -> When changes are made to the lang spec that would break
legacy code, or require a different binary interface.

The second one is more difficult, and important IMO. The /d/abi.html
page in its current state is ridiculous. The way it is now, there are no
parameters to tell what is acceptable as a D compiler output. Anyone
could create a D compiler which parses the language perfectly, but
generates code completely non-interoperable with both DMD and GDC, and
still call it a D compiler.

Miles (a D newsgroup lurker, who only occasionally posts)
July 23, 2006
Re: Is D 0.163 D 1.0?
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
July 23, 2006
Re: Is D 0.163 D 1.0?
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

A few more month's time for people to recommend changes!?!?  Phfff- we've
being doing that for years!   IMO, we've got the features we need for D
1.0.  A few more bug fixes would be nice (#146) but those can be done after
1.0.  More time for the new imports, sure, but no new features!  Let's do
this already!

-- 
~John Demme
me@teqdruid.com
http://www.teqdruid.com/
July 23, 2006
Re: Is D 0.163 D 1.0?
I've only just joined in the D community and have quite a few suggestions to 
make (and I believe they are all good ones). Whilst I don't want a 1.0 
release to be held up by me - as important as I am :) - I would like to 
understand how future D releases will handle breaking changes. For example, 
will breaking changes be avoided at all cost a la C++ / Java or will there 
be leeway so that the language doesn't evolve into a plethora of deprecated 
APIs and bad practices to avoid (again, a la C++ / Java).

Kent Boogaart


"John Demme" <me@teqdruid.com> wrote in message 
news:e9usak$eag$1@digitaldaemon.com...
> 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
>
> A few more month's time for people to recommend changes!?!?  Phfff- we've
> being doing that for years!   IMO, we've got the features we need for D
> 1.0.  A few more bug fixes would be nice (#146) but those can be done 
> after
> 1.0.  More time for the new imports, sure, but no new features!  Let's do
> this already!
>
> -- 
> ~John Demme
> me@teqdruid.com
> http://www.teqdruid.com/
1 2 3 4 5 6
Top | Discussion index | About this forum | D home