BLS wrote:
> Hi Walter,
> I think your question  should be dedicated to the library developers,
> because :
> D needs more stable libraries.
> Library development needs a feature freeze so ask them what is needed to
> create well designed long living libs. Implement it and name it 1.0.
> 
> Bjoern
> 
> 
> "Walter Bright" <newshound@digitalmars.com> schreef in bericht
> news:edctpl$12jt$1@digitaldaemon.com...
>> Any compelling reason why not? I know that everyone (including me) wants
>> more features, more improvements, etc., but nothing about calling it 1.0
>> will prevent that from happening.
> 
> 

/signed as a proposal

Kris? Sean?

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

Bruno Medeiros wrote:
> Walter Bright wrote:
>> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.
> 
> Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?

I'm beginning to think it's just Walter's impatience showing.  He wants to get 1.0 out sooner rather than later, so he keeps pushing us to let it happen.  But it isn't going to happen.  1.0 time will come when it's ready.  When both general and specific criteria are fulfilled.  See also digitalmars.D.bugs:8272, "d1.0blocker - anyone at home?"

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

Hi Kyle,
Sorry about my ignorance. Not sure to whom your reply belongs. If it is me :
The answere is :Not at all ! What about . DWT, DTL, some not yet written
native libs, and of
course the Java to D stuff.
IMO Lib.-Development requires a lot of time. So wether Walter named 166
1.0 including a feature freeze, or  he decided to implement requested
features until 1.0, again feature freezed.

Bjoern

"Kyle Furlong" <kylefurlong@gmail.com> schreef in bericht news:edea7q$2858$1@digitaldaemon.com...
> BLS wrote:
> > Hi Walter,
> > I think your question  should be dedicated to the library developers,
> > because :
> > D needs more stable libraries.
> > Library development needs a feature freeze so ask them what is needed to
> > create well designed long living libs. Implement it and name it 1.0.
> >
> > Bjoern
> >
> >
> > "Walter Bright" <newshound@digitalmars.com> schreef in bericht news:edctpl$12jt$1@digitaldaemon.com...
> >> Any compelling reason why not? I know that everyone (including me)
wants
> >> more features, more improvements, etc., but nothing about calling it
1.0
> >> will prevent that from happening.
> >
> >
>
> /signed as a proposal
>
> Kris? Sean?
>
> -- 
> Kyle Furlong // Physics Undergrad, UCSB
>
> "D is going wherever the D community wants it to go." - Walter Bright

BLS wrote:
> Hi Kyle,
> Sorry about my ignorance. Not sure to whom your reply belongs. If it is me :
> The answere is :Not at all ! What about . DWT, DTL, some not yet written
> native libs, and of
> course the Java to D stuff.
> IMO Lib.-Development requires a lot of time. So wether Walter named 166
> 1.0 including a feature freeze, or  he decided to implement requested
> features until 1.0, again feature freezed.
> 
> Bjoern
> 
> "Kyle Furlong" <kylefurlong@gmail.com> schreef in bericht
> news:edea7q$2858$1@digitaldaemon.com...
>> BLS wrote:
>>> Hi Walter,
>>> I think your question  should be dedicated to the library developers,
>>> because :
>>> D needs more stable libraries.
>>> Library development needs a feature freeze so ask them what is needed to
>>> create well designed long living libs. Implement it and name it 1.0.
>>>
>>> Bjoern
>>>
>>>
>>> "Walter Bright" <newshound@digitalmars.com> schreef in bericht
>>> news:edctpl$12jt$1@digitaldaemon.com...
>>>> Any compelling reason why not? I know that everyone (including me)
> wants
>>>> more features, more improvements, etc., but nothing about calling it
> 1.0
>>>> will prevent that from happening.
>>>
>> /signed as a proposal
>>
>> Kris? Sean?
>>
>> -- 
>> Kyle Furlong // Physics Undergrad, UCSB
>>
>> "D is going wherever the D community wants it to go." - Walter Bright
> 
> 

I mentioned Kris and Sean since they have some of the most extensive, public, and mature library code in the D community, of course, this doesnt marginalize the voice of other library writers.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

BCS wrote:

> Walter Bright wrote:
>> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.
> 
> Are you talking about DMD or D?
> 
> I think that all *D* needs is some editing of the spec (disambiguating, typo corrections, etc.) A feature freeze NOW wouldn't bug me a bit.
> 
> DMD on the other hand has a ways to go. I've got a few pet peeves* and there is a bunch of known issues under dstress and the issue list.
> 
> Lastly after D is declared 1.0 RCn, DMD should be confirmed to actually (for the most part) implement it correctly before it is declared 1.0. For that I'm thinking of a systematic sweep of the spec where test cases are generated for as many parts as can be managed. Each test case should be confirmed to work or be tagged as a correct program (a.k.a a known issue).
> 
> Submitting these to dstress might be a good idea also.
> 
> *> http://d.puremagic.com/issues/show_bug.cgi?id=52

I think this is an important distinction to make. The D spec may be ready and DMD might be ready on Windows too, but the Linux version is far from being usable for any kind of production environment. Once DMD on Linux generates correct debug information, allows the creation of shared libraries and has no code generation problems (see http://d.puremagic.com/issues/show_bug.cgi?id=315) we could probably talk about it.

Is the Linux DMD version intended to be part of the 1.0 release?

Well Kyle.
D-Language -> D-Libraries -> D-Tools -> D-DeveloperSatisfaction  ->
D-RealWorldApplications  -> D-Application-EndUserSatisfaction ->
(Commercial) Success ->
 D-LanguageEvolution -> (loop)
So what do whe have  here : A  typical chaotic self-dynamic process.
(Feature Freeze !)
Bjoern



"Kyle Furlong" <kylefurlong@gmail.com> schreef in bericht news:edeqqn$2mbb$1@digitaldaemon.com...
> BLS wrote:
> > Hi Kyle,
> > Sorry about my ignorance. Not sure to whom your reply belongs. If it is
me :
> > The answere is :Not at all ! What about . DWT, DTL, some not yet written
> > native libs, and of
> > course the Java to D stuff.
> > IMO Lib.-Development requires a lot of time. So wether Walter named 166
> > 1.0 including a feature freeze, or  he decided to implement requested
> > features until 1.0, again feature freezed.
> >
> > Bjoern
> >
> > "Kyle Furlong" <kylefurlong@gmail.com> schreef in bericht news:edea7q$2858$1@digitaldaemon.com...
> >> BLS wrote:
> >>> Hi Walter,
> >>> I think your question  should be dedicated to the library developers,
> >>> because :
> >>> D needs more stable libraries.
> >>> Library development needs a feature freeze so ask them what is needed
to
> >>> create well designed long living libs. Implement it and name it 1.0.
> >>>
> >>> Bjoern
> >>>
> >>>
> >>> "Walter Bright" <newshound@digitalmars.com> schreef in bericht news:edctpl$12jt$1@digitaldaemon.com...
> >>>> Any compelling reason why not? I know that everyone (including me)
> > wants
> >>>> more features, more improvements, etc., but nothing about calling it
> > 1.0
> >>>> will prevent that from happening.
> >>>
> >> /signed as a proposal
> >>
> >> Kris? Sean?
> >>
> >> -- 
> >> Kyle Furlong // Physics Undergrad, UCSB
> >>
> >> "D is going wherever the D community wants it to go." - Walter Bright
> >
> >
>
> I mentioned Kris and Sean since they have some of the most extensive, public, and mature library code in the D community, of course, this doesnt marginalize the voice of other library writers.
>
> -- 
> Kyle Furlong // Physics Undergrad, UCSB
>
> "D is going wherever the D community wants it to go." - Walter Bright

BLS wrote:
> Well Kyle.
> D-Language -> D-Libraries -> D-Tools -> D-DeveloperSatisfaction  ->
> D-RealWorldApplications  -> D-Application-EndUserSatisfaction ->
> (Commercial) Success ->
>  D-LanguageEvolution -> (loop)
> So what do whe have  here : A  typical chaotic self-dynamic process.
> (Feature Freeze !)
> Bjoern
> 
> 
> 
> "Kyle Furlong" <kylefurlong@gmail.com> schreef in bericht
> news:edeqqn$2mbb$1@digitaldaemon.com...
>> BLS wrote:
>>> Hi Kyle,
>>> Sorry about my ignorance. Not sure to whom your reply belongs. If it is
> me :
>>> The answere is :Not at all ! What about . DWT, DTL, some not yet written
>>> native libs, and of
>>> course the Java to D stuff.
>>> IMO Lib.-Development requires a lot of time. So wether Walter named 166
>>> 1.0 including a feature freeze, or  he decided to implement requested
>>> features until 1.0, again feature freezed.
>>>
>>> Bjoern
>>>
>>> "Kyle Furlong" <kylefurlong@gmail.com> schreef in bericht
>>> news:edea7q$2858$1@digitaldaemon.com...
>>>> BLS wrote:
>>>>> Hi Walter,
>>>>> I think your question  should be dedicated to the library developers,
>>>>> because :
>>>>> D needs more stable libraries.
>>>>> Library development needs a feature freeze so ask them what is needed
> to
>>>>> create well designed long living libs. Implement it and name it 1.0.
>>>>>
>>>>> Bjoern
>>>>>
>>>>>
>>>>> "Walter Bright" <newshound@digitalmars.com> schreef in bericht
>>>>> news:edctpl$12jt$1@digitaldaemon.com...
>>>>>> Any compelling reason why not? I know that everyone (including me)
>>> wants
>>>>>> more features, more improvements, etc., but nothing about calling it
>>> 1.0
>>>>>> will prevent that from happening.
>>>> /signed as a proposal
>>>>
>>>> Kris? Sean?
>>>>
>>>> -- 
>>>> Kyle Furlong // Physics Undergrad, UCSB
>>>>
>>>> "D is going wherever the D community wants it to go." - Walter Bright
>>>
>> I mentioned Kris and Sean since they have some of the most extensive,
>> public, and mature library code in the D community, of course, this
>> doesnt marginalize the voice of other library writers.
>>
>> -- 
>> Kyle Furlong // Physics Undergrad, UCSB
>>
>> "D is going wherever the D community wants it to go." - Walter Bright
> 
> 

Nice break down, I believe it is time to move to the library building phase in earnest, so like you said, RC1 it is.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

Walter Bright wrote:
> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.

I'm in favor of a spec feature freeze now and considering that 1.0.  A few refinements may be worthwhile here and there, but I don't see the need for any actual new features at this point.


Sean

Walter Bright wrote:
> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.

Firstly, I don't think things like fancy delegates with functional programming are very important for 1.0.  They are cool, but can wait.

I see some things that should be implemented before RC1 for backwards compatibility reasons, like auto and constness.  There is a way around that for the most part though:

I would like to see an experimental branch before seeing an RC, sort of like Gregor suggested.  Not a branch of the compiler, but a branch of the spec.  Features that are not stable or not implemented yet would fall into this experimental branch.  There would be a singular DMD that conforms to this spec, with the realization that any feature from the experimental part of the spec my change in the next release.

Here are some things I'd expect to see in the experimental spec:
- Lazy delegates // very new stuff
- auto // due to auto auto, this will get changed sometime right?
- array operators // not implemented yet
- common func ptr/delegate syntax // not implemented yet
- IFTI // not fully implemented
- mixins // I've read complaints about the usability of mixins
and so on...

It may even be nice to have a couple phases of experimental spec, like an alpha spec and a beta spec.  The alpha spec contains things that will most likely change, and the beta spec contains fairly stable features that are yet to be time-tested.

This would allow 1.0 to roll out without some of those things I've listed being addressed.  I don't think those features I've mentioned as experimental spec candidates are super important.  The only reason we worry about some of these, like auto auto, are for backwards compatibility.  But with an experimental system, coders are prewarned, and backwards compatibility isn't too worrisome.  Still, something like constness still bugs me even with experimental spec, since it could change very basic things about the language.


If 1.0 isn't a publicity thing, then disregard the below.  These assume that many new programmers will be trying D when a 1.0 release happens, and will need impressing.

Another big problem I see with RC1 - Access violation.  If there is going to be a mob of people trying D at 1.0, then the compiler should behave nicely, and not produce programs that produce 'access violation'.  This seems very tacky to me.  It turns a 30 second code correction into a 10+ minute debugging session, ouch!  At least put line numbers on those things.  Bonus points for decent descriptions of what went wrong.

Also related to mobs of people trying D at 1.0 - the spec needs going over with a fine tooth comb.  This seems to be going on already, which is good.  The spec's coolness would go up a few notches if there was a spec-only keyword search option.  Do this *before* 1.0.

Phobos.  Maybe this can wait, but perhaps we should at least do some work to phobos' interface?  Make sure the naming is consistent with the D style guidelines.  It needs a *simple* way to read input from the console, and not some std.c.crap.  Also, 'atoi' (in std.string) is a horrible name for a function that turns a string into an integer, and we have overloading now, unlike C back in the day, so make it 'toInt' (which exists in std.conv, so why the dupe?).  This shouldn't be a big effort to expand phobos' functionality, just a time where we break everyone's code and deal with it so that future D programmers don't have to.  Adopting another library like Ares as standard and tweaking on it should work too, though I see that as harder to pull off.

Bruno Medeiros wrote:
> Walter Bright wrote:
>> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.
> 
> Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?

It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.