www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is D 0.163 D 1.0?

reply Walter Bright <newshound digitalmars.com> writes:
I think the title says it all.
Jul 22 2006
next sibling parent John Demme <me teqdruid.com> writes:
Walter Bright wrote:


 I think the title says it all.


My gut says no, the sole reason being that some non-trivial changes were
made in .163 and they need some time to percolate... I think we need about
two weeks with these changes to certify 0.163.  Personally, I really like
0.163, but don't feel comfortable making it 1.0 with new features in it.

Writing this was kinda painful, though, since I'd really like to see D 1.0
without delay.

-- 
~John Demme
me teqdruid.com
http://www.teqdruid.com/
Jul 21 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:

 I think the title says it all.


The title? not really; is that a rehtorical question implying that it 
is, or are you asking whether it should be?

if the latter, then ... wouldn't it be such a rush to declare D1.0 right 
when new code-breaking changes were made?
Jul 22 2006
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:

 I think the title says it all.


As part of the answer.. I've setup a 'flag' in bugzilla called 
'd1.0blocker'.  If there's a bug you feel should be considered a blocker 
for 1.0, please set the '?' state.  Walter has been setup as the only 
person who can change the ? request to a + approved or - denied state.

I suggest that discussions for specific bugs and why they should or 
should not be blockers for 1.0 be taken to the .bugs newsgroup and not 
be part of this thread.

---

As to my opinion.  0.163 fixed one of the bigger outstanding issues, but 
I'd like to suggest that this release be given time to bake and that 
users be given some time to explore it for problems.  That will give you 
some time to work through some of the known bugs.

A gut feeling suggests that some time should be spent on linking and 
debugging related bugs.  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.

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

Later,
Brad
Jul 22 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Brad Roberts wrote:

 I suggest that discussions for specific bugs and why they should or 
 should not be blockers for 1.0 be taken to the .bugs newsgroup and not 
 be part of this thread.


It's really hard to say when a compiler is debugged or not. DMC++ has 
been around for 23 years and bugs still crop up in it.

Declaring the compiler "1.0" won't impede the regular flow of bug fixes 
and updates, what it does is say the feature set is 1.0 and the compiler 
is usable.
Jul 22 2006
parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:

 Brad Roberts wrote:

 I suggest that discussions for specific bugs and why they should or 
 should not be blockers for 1.0 be taken to the .bugs newsgroup and not 
 be part of this thread.


 
 It's really hard to say when a compiler is debugged or not. DMC++ has 
 been around for 23 years and bugs still crop up in it.
 
 Declaring the compiler "1.0" won't impede the regular flow of bug fixes 
 and updates, what it does is say the feature set is 1.0 and the compiler 
 is usable.


Agreed.. 1.0-ness is most about feature stability, but not exclusively. 
  That's one reason I suggested to take specific bug aspect out of this 
thread and over to .bugs.  Let this one stay more feature focused.

Later,
Brad
Jul 22 2006
prev sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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


-----BEGIN PGP SIGNATURE-----

iD8DBQFEwi8SLK5blCcjpWoRAuZ4AJwN6Nb3o7/XXQOMtRDJRCwUbPgI+wCfW8rL
NMXSkaB3fLESlpIQ5AD1jEg=
=9VXU
-----END PGP SIGNATURE-----
Jul 22 2006
prev sibling next sibling parent S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-07-22 00:30:35 -0700, Walter Bright <newshound digitalmars.com> said:


 I think the title says it all.


Me wants:

Array literals
initalizers
template libraries (dmd doesn't automatically compile in the 
appropriate files that are required for template generation.....)
Jul 22 2006
prev sibling next sibling parent reply "Tony" <ignorethis nowhere.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e9sk71$2u86$1 digitaldaemon.com...

I think the title says it all.


Do you intend to make any further changes that would break existing code?

Tony
Melbourne, Australia
Jul 22 2006
parent Walter Bright <newshound digitalmars.com> writes:
Tony wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e9sk71$2u86$1 digitaldaemon.com...

 I think the title says it all.


 
 Do you intend to make any further changes that would break existing code?


Not to anything starting with "1.", unless it is to fix a clear 
implementation bug. As D evolves, it's certainly possible that "2." may 
break existing code in small ways, as other languages do.

What I expect is that the "1.xx" series will focus on stability and bug 
fixes, while "2.xx" will be looking forward to being a significant 
upgrade in features.
Jul 22 2006
prev sibling next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:

 I think the title says it all.


What about standardizing the ABI?

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 22 2006
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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
Jul 22 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
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
Jul 22 2006
prev sibling parent reply Reiner Pope <reiner.pope gmail.com> writes:
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.
Jul 24 2006
parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
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
Jul 24 2006
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 I think the title says it all.


I say it's ready for 1.0.
Jul 22 2006
parent reply clayasaurus <clayasaurus gmail.com> writes:
Dave wrote:

 Walter Bright wrote:

 I think the title says it all.


 
 I say it's ready for 1.0.


vote++
Jul 22 2006
parent reply Gregor Richards <Richards codu.org> writes:
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
Jul 22 2006
next sibling parent reply John Demme <me teqdruid.com> writes:
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.  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/
Jul 22 2006
next sibling parent reply "Kent Boogaart" <kentcb internode.on.net> writes:
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

 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/
Jul 22 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Kent Boogaart wrote:

 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).


I think there's a reasonable middle ground.
Jul 22 2006
prev sibling parent John Demme <me teqdruid.com> writes:
Believe me, I understand this.  When I joined the D community a few years
ago, I had the same experience.  In fact, one of the first big things I
wanted got in! (The package visibility level)

Unfortunately, there are always people joining with ideas.  Frankly, some
are not for D.  Most, however, are great ideas but really don't make sense
for D 1.0.  We'd all like to see D be perfect, but we can do the idea
collection thing forever and still not see anything close to perfection.

Even when I was a D neophyte there were people saying that we have enough
and to release 1.0, and since I had some stuff to add I disagreed- now I'm
on the other end, I guess.  I've noticed that most of the recent features
are much higher level than the stuff being proposed a few years ago (better
synchronization/locking, full closures, ect., versus package keywords and
DLL support.)  Given this, I feel we are at a good point- feature wise- to
say we're at 1.0.  Then we have another 160-some-odd builds until 2.0 to
get the higher level stuff, right?!

~John

Kent Boogaart wrote:


 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

 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/




-- 
~John Demme
me teqdruid.com
http://www.teqdruid.com/
Jul 22 2006
prev sibling parent Gregor Richards <Richards codu.org> writes:
John Demme 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


 
 
 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.  More time for the new imports, sure, but no new features!  Let's do
 this already!
 


It has nothing to do with how long it's been being worked on, it has to 
do with how stable the codebase is.  Clearly it's still in flux.  In 
flux is not a good time to release a point-oh.

  - Gregor Richards
Jul 23 2006
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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
Jul 23 2006
parent Gregor Richards <Richards codu.org> writes:
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
Jul 23 2006
prev sibling next sibling parent Jason O'Brien <xergen hotmail.com> writes:
Please put some sort of mock pinning in 1.0 so it's possible to write 
code compatible for 2.0 :( (see other thread)
Jul 22 2006
prev sibling next sibling parent Miles <_______ _______.____> writes:
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)
Jul 22 2006
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
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.

-- 
~John Demme
me teqdruid.com
http://www.teqdruid.com/
Jul 22 2006
next sibling parent reply Reiner Pope <reiner.pope gmail.com> writes:
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.
 


I like this idea. I also know that other people have said before that a 
1.0 release should be quite polished, and that libraries are important. 
It seems that one of the major reasons for a 1.0 release is to act as 
one strong push to boost the D awareness. It is important to do this in 
one push as opposed to incremental releases (ie 1.0 language specs, then 
1.0 compiler, and then a 1.0 standard library release) because if people 
are not satisfied the first time they look at D, they are less likely to 
look later. As a result, it is better to spend a small time polishing it 
now, to make a great 1.0 release as opposed to an OK one.

Put simply, a 1.0 release should be a strong hit which persuades people 
to drop their current language and change to D. As a convert from 

support, and for every person who ignores that problem when coming to D, 
there will be many who don't. I know that there are many libraries 
around the place, like mango, the GUI libraries and mintl and dtl, so 
D's problem is not so much a lack of libraries, but rather a lack of 
*organised* libraries.

If we call 0.163 a release candidate, then, as John said, the library 
maintainers can update them to work with a future 1.0 release. Then, 
IMHO, D should stay at a frozen stage while we organize the libraries 

on the part of Walter in order to give an official stamp of approval, 
but the easier we make D for people, the more likely they are to want to 
join it.

Cheers,

Reiner
Jul 22 2006
parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Reiner Pope wrote:


 I like this idea. I also know that other people have said before that a 
 1.0 release should be quite polished, and that libraries are important. 


It seems to me that an official 1.0 release will encourage library 
writers who might be waiting for D to stablize before investing too much 
time creating libraries for it. Everyone knows that "1.0" means "first 
cut." I don't think extensive libraries are necessary at this point. 
Relative stability of language features, however, would be desirable so 
that extensive libraries could be created without too much reworking 
later on.

Peter
Jul 23 2006
parent reply Reiner Pope <reiner.pope gmail.com> writes:
Peter C. Chapin wrote:


 It seems to me that an official 1.0 release will encourage library 
 writers who might be waiting for D to stablize before investing too much 
 time creating libraries for it. Everyone knows that "1.0" means "first 
 cut." I don't think extensive libraries are necessary at this point. 
 Relative stability of language features, however, would be desirable so 
 that extensive libraries could be created without too much reworking 
 later on.
 
 Peter


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." So if someone believes this 
and then finds that it doesn't come with the built-in libraries they 
wanted, all of a sudden D is going to use a potential user, because 
they're not likely to come back and try again later unless they were 
_extremely_ dedicated.

Cheers,

Reiner
Jul 23 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
Reiner Pope wrote:

 Peter C. Chapin wrote:
 

 It seems to me that an official 1.0 release will encourage library 
 writers who might be waiting for D to stablize before investing too 
 much time creating libraries for it. Everyone knows that "1.0" means 
 "first cut." I don't think extensive libraries are necessary at this 
 point. Relative stability of language features, however, would be 
 desirable so that extensive libraries could be created without too 
 much reworking later on.

 Peter


 
 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


I wonder about that. I'd be willing to bet that the most popular OSS 
projects were all past 1.0 before they became really popular, especially 
languages, compilers and/or runtimes. Perl is at 5.6, Python is at 2.5, 
Ruby is at 1.8 (but that's deceptive), Java is at (effectively) about 
version 5. D has been at this for about 5-6 years, about the same amount 
of time for C++ and Java before they became "commercial quality" hits.

GCC wasn't considered stable enough for "real work" until v2.9.x or so, 
and GCC implemented pre-defined languages, not new ones. I get the 
feeling that G++ wasn't considered ready for prime time until 3.3.x or so.


 to 2.0 or beyond. IMHO it really means, "we've got a complete product 


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. In other 
words by objective measurement we may already have a "complete product" 
as far as the compilers and language spec. go.


 now, you should have no problems with it." So if someone believes this 


Version 5 of Perl was "the one". Before that (IIRC) there were a lot of 
quality issues, and after v5 the number and quality of Perl libs. has 
exploded.


 and then finds that it doesn't come with the built-in libraries they 
 wanted, all of a sudden D is going to use a potential user, because 


I think there have probably been many people who've given D the once 
over and said "interesting, but v0.1xx - too early" and not taken a 
second look or tried it. If they had tried it I think they would've 
probably seen that it was stable enough to contribute a few library 
functions for. In other words, the libs. aren't going to come until 
after many people try it, but many people won't try it until after v1.0 
because they won't spend the time on something they see as "alpha quality".


 they're not likely to come back and try again later unless they were 
 _extremely_ dedicated.
 


I think most of us who've tried D would profess that once you try it 
there are so many advantages to it that it is definitely worth watching. 
The problem has been that people see "v0.1xx" with a cursory look and 
decide "it's not even in alpha yet" by virtue of the version number.

A stable language def. labeled v1.x will encourage the library 
development, IMHO.

Here's how I see things playing out, I could be wrong of course:

a) D at v1.0, people start writing small programs best done in C but 
done in scripting languages now because of the built-in arrays, etc.
b) As more small programs are developed, they will inspire lib. 
development and larger programs.
c) D with large, high-quality libs. developed in the crucible of real 
world usage will take over the world <g>

One of the great things about Java early on was the huge libraries. One 
of the worst things about the huge libraries was that much of them were 
buggy and very slow and had to be re-written anyhow. The first Java 
libs. synchronized everything, so then subsequent releases had to 
introduce new objects that weren't synchronized and people had to 
re-write code to take advantage of them and now the non-synchronized 
versions are probably used more often than the original in many cases. 
In the meantime Java got the reputation as very slow in large part 
because of all of the synchronized objects - D can't afford something 
like that either.


 Cheers,
 
 Reiner
Jul 23 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
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. In other 
 words by objective measurement we may already have a "complete product" 
 as far as the compilers and language spec. go.


It isn't unusual for a professional compiler system out there to have 
thousands of unresolved items in the internal bug database.

The crucial question is if those problems impede the normal use of the 
product.
Jul 23 2006
prev sibling parent "Peter C. Chapin" <pchapin sover.net> writes:
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
Jul 23 2006
prev sibling parent reply "Peter C. Chapin" <pchapin sover.net> writes:
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
Jul 23 2006
parent Reiner Pope <reiner.pope gmail.com> writes:
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.
Jul 23 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
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.
Jul 23 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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>
Jul 24 2006
next sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
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
Jul 24 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
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_!
Jul 24 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
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
Jul 24 2006
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
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
Jul 24 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Oskar Linde wrote:

 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


What is partial specialization ? And Partial template instantiation? 
(does that come from C++?)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 27 2006
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Bruno Medeiros wrote:

 Oskar Linde wrote:

 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


 
 What is partial specialization ? And Partial template instantiation? 
 (does that come from C++?)


The term "partial specialization" isn't mentioned in the D spec, but its 
meaning is documented under "Specialization" in 
http://www.digitalmars.com/d/template.html
It basically means that you can specialize a template for e.g. all pointers:
template tmp(T:T*) {...}

By partial template instantiation (I have no idea if this is the correct 
term), I mean specializing a template partially explicitly and partially 
implicitly.  E.g:

A myCast(A,B)(B x) { return cast(A)x; }
...
myCast!(float)(5);

No template declaration fully matches myCast!(float). It gets partially 
instantiated and the remaining template parameter B is automatically 
deduced.

/Oskar
Jul 28 2006
next sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Oskar Linde wrote:

 Bruno Medeiros wrote:

 Oskar Linde wrote:

 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


 What is partial specialization ? And Partial template instantiation? 
 (does that come from C++?)


 
 The term "partial specialization" isn't mentioned in the D spec, but its 
 meaning is documented under "Specialization" in 
 http://www.digitalmars.com/d/template.html
 It basically means that you can specialize a template for e.g. all 
 pointers:
 template tmp(T:T*) {...}
 
 By partial template instantiation (I have no idea if this is the correct 
 term), I mean specializing a template partially explicitly and partially 
 implicitly.  E.g:
 
 A myCast(A,B)(B x) { return cast(A)x; }
 ...
 myCast!(float)(5);
 
 No template declaration fully matches myCast!(float). It gets partially 
 instantiated and the remaining template parameter B is automatically 
 deduced.


An interesting question is if there really is a huge need for this in D. 
D's templates are already more powerful than C++, and the above example 
can be written:

template myCast(A) {
	A myCast(B)(B x) {
		return cast(A)x;	
	}
}

(C++ will get this too, one day)

The difference to C++ is (in D syntax), given:

A func(A,B)(B x) { return 1; }
A func(A)(double x) { return 0; }

Then:

In C++, func!(int)(5) would return 1, whereas in D, without partial 
template instantiation, it would return 0.

C++ may make this more complicated than necessary. IMHO, C++ has too 
many different ways of achieving polymorphism and they all work together 
making the overload resolution overly complicated.

/Oskar
Jul 28 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Oskar Linde wrote:

 Bruno Medeiros wrote:

 Oskar Linde wrote:

 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


 What is partial specialization ? And Partial template instantiation? 
 (does that come from C++?)




Oops, I was going to google a bit before asking, but the message got 
sent first. I still searched, so I would know how it is done in C++ (I 
know basic C++, but not C++ templates).


 
 The term "partial specialization" isn't mentioned in the D spec, but its 
 meaning is documented under "Specialization" in 
 http://www.digitalmars.com/d/template.html
 It basically means that you can specialize a template for e.g. all 
 pointers:
 template tmp(T:T*) {...}
 


Yup, it's pretty much the same concept as C++.

Speaking about the doc, the "Specialization" section should appear 
sooner, since there are many references to specialization before its 
section. Also, on point 2 of Argument Deduction:
"2. If the type specialization is dependent on a type parameter, the 
type of ... " is a bit ambiguous IMO on the "dependent on a type 
parameter" part, as it is not clear that such depended type parameter 
must be the respective parameter of *that specialization*, and not any 
other type parameter of the template. It's the difference between these 
two cases:

   T : T*
   T : U*


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 29 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
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.
Jul 24 2006
parent Walter Bright <newshound digitalmars.com> writes:
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.
Jul 24 2006
prev sibling next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Sat, 22 Jul 2006 03:30:35 -0400, Walter Bright  
<newshound digitalmars.com> wrote:


 I think the title says it all.


I'm not sure, but I think at least what should be done first is to go  
through all the specifications and documentation carefully and make sure  
nothing is missing. All the "to be defined"s and fuzzy areas, and such  
things should be examined and cleared up. During this, some things may be  
found needing serious attention that are very much better addressed before  
1.0.
Jul 22 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Chris Miller wrote:

 On Sat, 22 Jul 2006 03:30:35 -0400, Walter Bright 
 <newshound digitalmars.com> wrote:
 

 I think the title says it all.


 
 I'm not sure, but I think at least what should be done first is to go 
 through all the specifications and documentation carefully and make sure 
 nothing is missing. All the "to be defined"s and fuzzy areas, and such 
 things should be examined and cleared up. During this, some things may 
 be found needing serious attention that are very much better addressed 
 before 1.0.


vote++

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
Jul 23 2006
prev sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Chris Miller wrote:


 On Sat, 22 Jul 2006 03:30:35 -0400, Walter Bright
 <newshound digitalmars.com> wrote:
 

 I think the title says it all.


 
 I'm not sure, but I think at least what should be done first is to go
 through all the specifications and documentation carefully and make sure
 nothing is missing. All the "to be defined"s and fuzzy areas, and such
 things should be examined and cleared up. During this, some things may be
 found needing serious attention that are very much better addressed before
 1.0.


Yes, there're many such areas. Better have a checklist.
Is it okay to post 'em to bugzilla?

-- 
AKhropov
Jul 23 2006
parent Walter Bright <newshound digitalmars.com> writes:
Andrei Khropov wrote:

 Yes, there're many such areas. Better have a checklist.
 Is it okay to post 'em to bugzilla?


Yes.
Jul 23 2006
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:

 I think the title says it all.


It didn't take me long to figure out that that's a rhetorical question, 
but I'm still pondering over why you asked it.

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.
Jul 23 2006
prev sibling next sibling parent reply Paolo Invernizzi <arathorn NOSPAM_fastwebnet.it> writes:
Please, another last effort... array initializers.

My 2c...

---
Paolo

Walter Bright wrote:

 I think the title says it all.
Jul 23 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Paolo Invernizzi wrote:

 Please, another last effort... array initializers.
 
 My 2c...
 
 ---
 Paolo
 
 Walter Bright wrote:
 

 I think the title says it all.




I agree.  Although, for the moment, we do have this solution:




I'd say this (along with some other things) should get moved into a 'std.array'
module at 
the very least, if we're going 1.0 now.

-- Chris Nicholson-Sauls
Jul 23 2006
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:

 I think the title says it all.


Sounds good.

How about declaring 0.163 RC1, taking 2 a weeks "no-touching-computers" 
leave, and trying to get some distance to all this. Go talk with folks, 
spend time with the kids and wife (if she's still around?), let your 
sub-conscious mind wind down, perceive the world. (No joke, seriously.)

I think D is as good as we need it to be right now.

When you come back, folks will have made some progress with the 
libraries, new thoughts on how to tackle the publicity issues, packaging 
of DMD, and hopefully some really novel ideas, will have emerged.

And there's still time to lay out the groundwork before September. 
(Early September being the time that defines what folks will be doing 
for the next 9 months.)

As I see it, there are two areas where D outshines about any other 
language: the academia (both research and education), and writing 
mathematical and scientific applications. (Fortan is clunky and passe, 
C++ can kill a good scientist, Pascal is out-dated, interpreted 
languages are just too slow, and the Lisp-ish compiled languages are too 
hard to understand anyway for the casual academic, who is mainly 
interested in pursuing his own research.)

We might have some ideas for inroads when you come back.
Jul 23 2006
prev sibling next sibling parent "Bob W" <nospam aol.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e9sk71$2u86$1 digitaldaemon.com...

I think the title says it all.


D 0.163 isn't 1.0, but I guess we are getting pretty close to it.
Otherwise you wouldn't have started this survey, right?      ;-)
Jul 23 2006
prev sibling next sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
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
Jul 23 2006
next sibling parent "Bob W" <nospam aol.com> writes:
"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 ....
Jul 23 2006
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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.













yes?  (I 

Precedence has 
been established for it.  It shouldn't be un-intuitive to many people.

-- Chris Nicholson-Sauls
Jul 23 2006
next sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Chris Nicholson-Sauls wrote:



 inference, yes?




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
Jul 24 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Chris Nicholson-Sauls wrote:

 

 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
Jul 24 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 24 Jul 2006 06:58:39 -0700, Sean Kelly <sean f4.ca> wrote:

 Chris Nicholson-Sauls wrote:


 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.


I'd prefer scoped destruction to simply omit the 'new' keyword, eg.

class A {}

A a = new A(); //normal
A a = A(); //destroyed at end of scope

and with auto..

auto a = new A(); //normal
auto a = A(); //destroyed at end of scope

Simple, elegant, obvious (IMO)

Regan
Jul 24 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Regan Heath wrote:

 On Mon, 24 Jul 2006 06:58:39 -0700, Sean Kelly <sean f4.ca> wrote:

 Chris Nicholson-Sauls wrote:


 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.


 
 I'd prefer scoped destruction to simply omit the 'new' keyword, eg.
 
 class A {}
 
 A a = new A(); //normal
 A a = A(); //destroyed at end of scope
 
 and with auto..
 
 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope
 
 Simple, elegant, obvious (IMO)


I like this too, though it doesn't address being able to label a class 
as 'auto'.  But perhaps that syntax can stay as-is?


Sean
Jul 24 2006
parent reply Dave <Dave_member pathlink.com> writes:
Sean Kelly wrote:

 Regan Heath wrote:

 On Mon, 24 Jul 2006 06:58:39 -0700, Sean Kelly <sean f4.ca> wrote:

 Chris Nicholson-Sauls wrote:


 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.


 I'd prefer scoped destruction to simply omit the 'new' keyword, eg.

 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO)


 


So do I.


 I like this too, though it doesn't address being able to label a class 
 as 'auto'.  But perhaps that syntax can stay as-is?
 


I think so too.


 
 Sean
Jul 24 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 24 Jul 2006 17:48:52 -0500, Dave <Dave_member pathlink.com> wrote:

 Sean Kelly wrote:

 Regan Heath wrote:

 On Mon, 24 Jul 2006 06:58:39 -0700, Sean Kelly <sean f4.ca> wrote:

 Chris Nicholson-Sauls wrote:


 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.


 I'd prefer scoped destruction to simply omit the 'new' keyword, eg.

 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO)




 So do I.


 I like this too, though it doesn't address being able to label a class  
 as 'auto'.  But perhaps that syntax can stay as-is?


 I think so too.


Or the keyword can be changed to something else. I have to admit I've  
never really liked this usage of auto, it places restrictions on my usage  
of the class.. I prefer to have full control over how I use them, even if  
it means I might forget.

Regan
Jul 24 2006
parent Dave <Dave_member pathlink.com> writes:
Regan Heath wrote:

 On Mon, 24 Jul 2006 17:48:52 -0500, Dave <Dave_member pathlink.com> wrote:

 Sean Kelly wrote:

 Regan Heath wrote:

 On Mon, 24 Jul 2006 06:58:39 -0700, Sean Kelly <sean f4.ca> wrote:

 Chris Nicholson-Sauls wrote:


 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.


 I'd prefer scoped destruction to simply omit the 'new' keyword, eg.

 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO)




 So do I.


 I like this too, though it doesn't address being able to label a 
 class as 'auto'.  But perhaps that syntax can stay as-is?


 I think so too.


 
 Or the keyword can be changed to something else. I have to admit I've 
 never really liked this usage of auto, it places restrictions on my 
 usage of the class.. I prefer to have full control over how I use them, 
 even if it means I might forget.
 
 Regan


Heck, I don't care if it stays 'auto class ...' or not unless that makes 
it more likely for the first idea to be implemented :)

The problem I can see with 'A a = A()' would be that people would expect 
it to be stack allocated (and that's never going to happen for v1.0) but 
it is still my preference over the long haul so I'd live with it.

Auto type inference and auto dtors are both great features and it's a 
shame if they couldn't be used together, though personally I don't think 
this should hold v1.0 up because there is a simple workaround.
Jul 24 2006
prev sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Regan Heath wrote:


 I'd prefer scoped destruction to simply omit the 'new' keyword, eg.
 
 class A {}
 
 A a = new A(); //normal
 A a = A(); //destroyed at end of scope
 
 and with auto..
 
 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope
 
 Simple, elegant, obvious (IMO)
 
 Regan


Well, it may be a solution, but I personally regard 'new' as a visual cue that
indicates that memory is allocated from the heap.

But considering your proposal we should get rid of 'auto class' too,
because 'auto' should mean only one thing - be it scope lived classes or type
inference.

I think it's easier to change type inference syntax since it's a relatively
recent addition and hence it'll break less code.

-- 
AKhropov
Jul 24 2006
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
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!)
Jul 24 2006
prev sibling next sibling parent reply renox <renosky free.fr> writes:
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)


You have my vote too.
Jul 24 2006
parent reply Don Clugston <dac nospam.com.au> writes:
renox wrote:

 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)


 
 You have my vote too.


Nooooooooo!!!!
Am I the only person who has hundreds of local variables called 'var'?
(mostly variants in Win32 code).

A quick google search for 'var cpp' showed a million hits, a fair chunk 
of them are local variables in C++ code. It's a very popular variable name.
Jul 25 2006
next sibling parent reply Derek <derek psyc.ward> writes:
On Tue, 25 Jul 2006 10:31:53 +0200, Don Clugston wrote:

 

 Nooooooooo!!!!
 Am I the only person who has hundreds of local variables called 'var'?
 (mostly variants in Win32 code).


LOL! You deserve the pain then for choosing such a lame identifier!
 

 A quick google search for 'var cpp' showed a million hits, a fair chunk 
 of them are local variables in C++ code. It's a very popular variable name.



Oh my Bob! Doesn't anyone go to programming 101 anymore? Why make life hard
for yourself by picking identifier names that are likely to clash with
keywords *and* that don't help code readers.


[a] Ensure your identifiers are not valid English words.
[b] Ensure your identifiers either contain a mix of UPPER and
    lowercase characters or contain an underscore or both.
[c] Ensure your identifiers never contain digits.
[d] Ensure your identifiers have at least three (3) characters.
 - Exceptions -
 [e] Single character identifiers, which should always be lowercase.
 [f] Method names can be valid words, but must have mixed case.
 [g] Anything your supervisor signs off on.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Jul 25 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Derek wrote:

 On Tue, 25 Jul 2006 10:31:53 +0200, Don Clugston wrote:
  

 Nooooooooo!!!!
 Am I the only person who has hundreds of local variables called 'var'?
 (mostly variants in Win32 code).


 
 LOL! You deserve the pain then for choosing such a lame identifier!


Yes, it's as lame as 'x', and deliberately so.
It's lamer as a keyword, IMHO. It's not an English word. 'auto' has been 
widely promoted for exactly that purpose in C++, and 'var' had a 
completely different meaning in Pascal. I cannot understand the 
attraction to 'var'.


 A quick google search for 'var cpp' showed a million hits, a fair chunk 
 of them are local variables in C++ code. It's a very popular variable name.


 
 Oh my Bob! Doesn't anyone go to programming 101 anymore? Why make life hard
 for yourself by picking identifier names that are likely to clash with
 keywords *and* that don't help code readers.


Because meaningless local variables/parameters should not have 
meaningful names; otherwise, you're being _unhelpful_ to code readers!
The most common meaningless names I use are 'x', 'y', 'n', 'p', 'q', 
'val' and 'var', and 'arr'.

I guess I never went to programming 101.



 [a] Ensure your identifiers are not valid English words.
 [b] Ensure your identifiers either contain a mix of UPPER and
     lowercase characters or contain an underscore or both.
 [c] Ensure your identifiers never contain digits.


The main time I do this is with constructions of the form...

template (P1, P2, P3, P4)
void func(P1 p1, P2 p2, P3 p3, P4 p4)

(where you'd like them to be an array, but the language doesn't allow 
it). How would you do it?


 [d] Ensure your identifiers have at least three (3) characters.


Never heard that one before. What's the reason?


  - Exceptions -
  [e] Single character identifiers, which should always be lowercase.
  [f] Method names can be valid words, but must have mixed case.
  [g] Anything your supervisor signs off on.


Fine, but I think it's reasonable to assume that any new keyword will be 
either an English word, very obscure, or most likely both. Given that 
the number of new keywords will be *extremely* small, I don't think it 
makes much sense to have the risk of a collision be a major driver of 
naming convention. I really don't like your rule [b], when applied to 
local variables and parameter names, I think it reduces legibility, but 
I think it's reasonable for method names.
Jul 25 2006
next sibling parent Derek <derek psyc.ward> writes:
On Tue, 25 Jul 2006 15:20:13 +0200, Don Clugston wrote:


 Derek wrote:


 






LOL... It was a joke, sorry. I just scribbled down some junk without
thinking about it too deeply. I'm not pushing a barrow here.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Jul 25 2006
prev sibling next sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Don Clugston wrote:


 It's lamer as a keyword, IMHO. It's not an English word.


'var' is short for 'variable' like 'int' is short for 'integer'



 'auto' has been
 widely promoted for exactly that purpose in C++


Yes, but in C++ only. And don't forget that in C++ there is already a
(redundant but still valid) keyword 'auto' that means scoped variables like it
was in D before type inference:

This is a quote from "Stroustrup. The C++ programming language, 3rd ed":

--------------------------------------------------------------------------------

Automatic memory, in which function arguments and local variables are
allocated. Each entry into a function or a block gets its own copy. This kind
of memory is automatically created and destroyed; hence the name automatic
memory. Automatic memory is also said ‘‘to be on the stack.’’ If you absolutely
must be explicit about this, C++ provides the redundant keyword *auto*.
--------------------------------------------------------------------------------

So it would be also confusing in C++ if they accept this proposal.


 I cannot understand the attraction to 'var'.


Because it is meaningful (short for 'variable') and already used in several



P.S. And I like 'val' (from 'value') in Scala that means immutable variable (in
fact just named constant or value), compare:

--------------------
Scala: val i = 1;
--------------------
C++: const int i = 1;
--------------------

It's short and readable (IMHO).

-- 
AKhropov
Jul 25 2006
prev sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Don Clugston wrote:


 It's lamer as a keyword, IMHO. It's not an English word.


'var' is short for 'variable' like 'int' is short for 'integer'



 'auto' has been
 widely promoted for exactly that purpose in C++


Yes, but in C++ only. And don't forget that in C++ there is already a
(redundant but still valid) keyword 'auto' that means scoped variables like it
was in D before type inference:

This is a quote from "Stroustrup. The C++ programming language, 3rd ed":

--------------------------------------------------------------------------------

Automatic memory, in which function arguments and local variables are
allocated. Each entry into a function or a block gets its own copy. This kind
of memory is automatically created and destroyed; hence the name automatic
memory. Automatic memory is also said ‘‘to be on the stack.’’ If you absolutely
must be explicit about this, C++ provides the redundant keyword *auto*.
--------------------------------------------------------------------------------

So it would be also confusing in C++ if they accept this proposal.


 I cannot understand the attraction to 'var'.


Because it is meaningful (short for 'variable') and already used in several



P.S. And I like 'val' (from 'value') in Scala that means immutable variable (in
fact just named constant or value), compare:

--------------------
Scala: val i = 1;
--------------------
C++: const int i = 1;
--------------------

It's short and readable (IMHO).

-- 
AKhropov
Jul 25 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Andrei Khropov wrote:

 P.S. And I like 'val' (from 'value') in Scala that means immutable variable (in
 fact just named constant or value), compare:
 
 --------------------
 Scala: val i = 1;
 --------------------
 C++: const int i = 1;
 --------------------
 
 It's short and readable (IMHO).
 


D: const i = 1;

Its like a compromise.  ;)

-- Chris Nicholson-Sauls
Jul 25 2006
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Don Clugston wrote:

 Nooooooooo!!!!
 Am I the only person who has hundreds of local variables called 'var'?
 (mostly variants in Win32 code).
 
 A quick google search for 'var cpp' showed a million hits, a fair chunk 
 of them are local variables in C++ code. It's a very popular variable name.


Actually I do feel your pain, but I still vote for it.  Waaay back in the day I
used to do 
a lot of LambdaMOO server hacking, and therein I discovered my first Var
struct.  (That'd 
be about 1996 I think it was.)  Now, ten years later, I am working on
BovisMOO... and I'm 
still using a Var struct (albeit a much cleaner one), and plenty of temporary
Var's named, 
yes, 'var.'

But I can always just rename them to 'tmp', or something else.  (Actually a lot
of them 
would probably get renamed 'result' since that's what they generally are.)

-- Chris Nicholson-Sauls
Jul 25 2006
parent reply kris <foo bar.com> writes:
Chris Nicholson-Sauls wrote:

 Don Clugston wrote:
 

 Nooooooooo!!!!
 Am I the only person who has hundreds of local variables called 'var'?
 (mostly variants in Win32 code).

 A quick google search for 'var cpp' showed a million hits, a fair 
 chunk of them are local variables in C++ code. It's a very popular 
 variable name.


 
 
 Actually I do feel your pain, but I still vote for it.  Waaay back in 
 the day I used to do a lot of LambdaMOO server hacking, and therein I 
 discovered my first Var struct.  (That'd be about 1996 I think it was.)  
 Now, ten years later, I am working on BovisMOO... and I'm still using a 
 Var struct (albeit a much cleaner one), and plenty of temporary Var's 
 named, yes, 'var.'
 
 But I can always just rename them to 'tmp', or something else.  
 (Actually a lot of them would probably get renamed 'result' since that's 
 what they generally are.)
 
 -- Chris Nicholson-Sauls


I suspect the focus should be directed elsewhere, Chris?

There's nothing wrong with using "auto" for implicit-type -- it's the 
confusion with raii that's the issue, yes?

I suspect the ratio of raii usage to implicit-type usage would be 
overwhelmingly in favour of the latter. Thus, it would seem to make 
sense to leave implicit-type "auto" just as it is, and change raii to 
use something else instead; such as "scope" ?

void main()
{
   auto i = 10;
   auto foo = new Foo;
   auto scope bar = new Bar;
   auto scope wumpus = new Wumpus;
}

class Foo {}

class Bar {}

scope class Wumpus {}
Jul 25 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
kris wrote:

 Chris Nicholson-Sauls wrote:
 

 Don Clugston wrote:


 Nooooooooo!!!!
 Am I the only person who has hundreds of local variables called 'var'?
 (mostly variants in Win32 code).

 A quick google search for 'var cpp' showed a million hits, a fair 
 chunk of them are local variables in C++ code. It's a very popular 
 variable name.




 Actually I do feel your pain, but I still vote for it.  Waaay back in 
 the day I used to do a lot of LambdaMOO server hacking, and therein I 
 discovered my first Var struct.  (That'd be about 1996 I think it 
 was.)  Now, ten years later, I am working on BovisMOO... and I'm still 
 using a Var struct (albeit a much cleaner one), and plenty of 
 temporary Var's named, yes, 'var.'

 But I can always just rename them to 'tmp', or something else.  
 (Actually a lot of them would probably get renamed 'result' since 
 that's what they generally are.)

 -- Chris Nicholson-Sauls


 
 
 I suspect the focus should be directed elsewhere, Chris?
 
 There's nothing wrong with using "auto" for implicit-type -- it's the 
 confusion with raii that's the issue, yes?
 
 I suspect the ratio of raii usage to implicit-type usage would be 
 overwhelmingly in favour of the latter. Thus, it would seem to make 
 sense to leave implicit-type "auto" just as it is, and change raii to 
 use something else instead; such as "scope" ?
 
 void main()
 {
   auto i = 10;
   auto foo = new Foo;
   auto scope bar = new Bar;
   auto scope wumpus = new Wumpus;
 }
 
 class Foo {}
 
 class Bar {}
 
 scope class Wumpus {}
 


Actually that does make some sense, and I do like the meaningful re-use of an
existing 
keyword over inventing a new one.  (Honestly I hadn't even considered 'scope'
for this, 
even though it does make obvious sense!)  Although, I find myself almost
wanting to make 
it 'scoped' for this (note the -d on the end), as that's what it is really
meaning, but A) 
then it becomes a new keyword anyway, and B) it begs for typos.

I think you may've converted me.

-- Chris Nicholson-Sauls
Jul 25 2006
prev sibling parent reply Derek <derek psyc.ward> writes:
On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:


 And what about double meaning of 'auto'?


In general 'auto' is a poor choice for both meanings. 'auto' is obviously
shorthand for automatic, but automatic what??? 

Walter, given that 'auto' as a keyword is not going to be removed from the
language, how can one currently declare a type-inferred variable that has
RAII properties?

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Jul 24 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek wrote:

 On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:
 

 And what about double meaning of 'auto'?


 
 In general 'auto' is a poor choice for both meanings. 'auto' is obviously
 shorthand for automatic, but automatic what??? 
 
 Walter, given that 'auto' as a keyword is not going to be removed from the
 language, how can one currently declare a type-inferred variable that has
 RAII properties?
 


Regan Heath penned the solution I thought I'd posted a while back, but 
maybe I hadn't:


 class A {}
 
 A a = new A(); //normal
 A a = A(); //destroyed at end of scope
 
 and with auto..
 
 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope
 
 Simple, elegant, obvious (IMO)
Jul 25 2006
next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Walter Bright wrote:

 Derek wrote:
 

 On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:


 And what about double meaning of 'auto'?



 In general 'auto' is a poor choice for both meanings. 'auto' is obviously
 shorthand for automatic, but automatic what???
 Walter, given that 'auto' as a keyword is not going to be removed from 
 the
 language, how can one currently declare a type-inferred variable that has
 RAII properties?


 
 Regan Heath penned the solution I thought I'd posted a while back, but 
 maybe I hadn't:
 

 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO) 


 
 


Myself I would prefer not to have that.  It creates an ambiguity between 
  a static opCall on A and the storage attribute.
So:

class A
{
   static A opCall() { ...do something... }
}

A a = A(); // destroyed at end of scope, or call A.opCall()?

I prefer the storage attribute have it's own keyword.  Perhaps give 
storage 'auto' and type inference 'var'.  For me, that makes it more 
obvious, since to my eyes it would be a keyword that I've never seen 
before and now need to look up in the spec - otherwise it's just a 
static opCall :(.
Jul 25 2006
next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Chad J wrote:

 Walter Bright wrote:

 Derek wrote:


 On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:


 And what about double meaning of 'auto'?



 In general 'auto' is a poor choice for both meanings. 'auto' is 
 obviously
 shorthand for automatic, but automatic what???
 Walter, given that 'auto' as a keyword is not going to be removed 
 from the
 language, how can one currently declare a type-inferred variable that 
 has
 RAII properties?


 Regan Heath penned the solution I thought I'd posted a while back, but 
 maybe I hadn't:


 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO) 




 
 Myself I would prefer not to have that.  It creates an ambiguity between 
  a static opCall on A and the storage attribute.


I think "static opCall" is a hack to begin with. It's basically a 
workaround for structs not having constructors. For classes, there's no 
point in having a static opCall if Walter implements the "A()" construct.


 I prefer the storage attribute have it's own keyword.  Perhaps give 
 storage 'auto' and type inference 'var'.  For me, that makes it more 
 obvious, since to my eyes it would be a keyword that I've never seen 
 before and now need to look up in the spec - otherwise it's just a 
 static opCall :(.


I also prefer "var" to "auto" for the type inference. I don't think 
anybody expects "var" to be dynamically typed. Well, maybe a few. And 
then there's the "auto" from C++; it might confuse people if its meaning 
were changed.

L.
Jul 25 2006
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 25 Jul 2006 12:32:52 +0300, Lionello Lunesu  
<lio lunesu.remove.com> wrote:

 Chad J wrote:

 Walter Bright wrote:

 Derek wrote:


 On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:


 And what about double meaning of 'auto'?



 In general 'auto' is a poor choice for both meanings. 'auto' is  
 obviously
 shorthand for automatic, but automatic what???
 Walter, given that 'auto' as a keyword is not going to be removed  
 from the
 language, how can one currently declare a type-inferred variable that  
 has
 RAII properties?


 Regan Heath penned the solution I thought I'd posted a while back, but  
 maybe I hadn't:


 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO)




  Myself I would prefer not to have that.  It creates an ambiguity  
 between  a static opCall on A and the storage attribute.


 I think "static opCall" is a hack to begin with. It's basically a  
 workaround for structs not having constructors. For classes, there's no  
 point in having a static opCall if Walter implements the "A()" construct.


I agree.


 I prefer the storage attribute have it's own keyword.  Perhaps give  
 storage 'auto' and type inference 'var'.  For me, that makes it more  
 obvious, since to my eyes it would be a keyword that I've never seen  
 before and now need to look up in the spec - otherwise it's just a  
 static opCall :(.


 I also prefer "var" to "auto" for the type inference. I don't think  
 anybody expects "var" to be dynamically typed. Well, maybe a few. And  
 then there's the "auto" from C++; it might confuse people if its meaning  
 were changed.


I think Don's point about there being a lot of user variables called "var"  
makes "auto" a safer and IMO just as good choice.

Regan
Jul 25 2006
prev sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Lionello Lunesu wrote:

 
 
 I think "static opCall" is a hack to begin with. It's basically a 
 workaround for structs not having constructors. For classes, there's no 
 point in having a static opCall if Walter implements the "A()" construct.
 


I disagree.  I like being able to use types as functions.
Here's one example where I do something similar to what you'd use nested 
functions for, but better - my forward referencing woes go away.

class F
{
     int result;
     int tempVar1;

     static int opCall( int x )
     {
         F f = new F(x);
         int result = f.result;
         delete f;
         return result;
     }

     this( int x )
     {
         internalFunc1();
         // do stuff
     }

     private void internalFunc1()
     {
         if ( maybe )
             internalFunc2();
         else return;
     }

     private void internalFunc2()
     {
         if ( maybe )
             internalFunc1();
         else return;
     }
}

void main()
{
     int x = 42;
     x = F(x);
}

Under the hood, it may also behave differently than nested functions, 
which could be advantageous.  I'm not sure that it is advantageous, but 
options are always nice.

That and you can make nice syntax sugars for alternative memory 
management methods like freelists, without messing with overriding 'new()'.


 
 
 I also prefer "var" to "auto" for the type inference. I don't think 
 anybody expects "var" to be dynamically typed. Well, maybe a few. And 
 then there's the "auto" from C++; it might confuse people if its meaning 
 were changed.
 
 L.
Jul 25 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Chad J wrote:

 Walter Bright wrote:

 Derek wrote:


 On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:


 And what about double meaning of 'auto'?



 In general 'auto' is a poor choice for both meanings. 'auto' is 
 obviously
 shorthand for automatic, but automatic what???
 Walter, given that 'auto' as a keyword is not going to be removed 
 from the
 language, how can one currently declare a type-inferred variable that 
 has
 RAII properties?


 Regan Heath penned the solution I thought I'd posted a while back, but 
 maybe I hadn't:


 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO) 




 
 Myself I would prefer not to have that.  It creates an ambiguity between 
  a static opCall on A and the storage attribute.
 So:
 
 class A
 {
   static A opCall() { ...do something... }
 }
 
 A a = A(); // destroyed at end of scope, or call A.opCall()?
 
 I prefer the storage attribute have it's own keyword.  Perhaps give 
 storage 'auto' and type inference 'var'.  For me, that makes it more 
 obvious, since to my eyes it would be a keyword that I've never seen 
 before and now need to look up in the spec - otherwise it's just a 
 static opCall :(.


By the way, I'd suggested an alternate syntax that admittedly uses a new 
keyword:

A a = local A();

(or I suppose)

A a = auto A();

I think it's more appropriate to attach the keyword to the initializer 
rather than the declaration since the reference is just a reference 
either way.


Sean
Jul 25 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Chad J wrote:

 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO) 




 
 Myself I would prefer not to have that.  It creates an ambiguity between 
  a static opCall on A and the storage attribute.
 So:
 
 class A
 {
   static A opCall() { ...do something... }
 }
 
 A a = A(); // destroyed at end of scope, or call A.opCall()?
 
 I prefer the storage attribute have it's own keyword.  Perhaps give 
 storage 'auto' and type inference 'var'.  For me, that makes it more 
 obvious, since to my eyes it would be a keyword that I've never seen 
 before and now need to look up in the spec - otherwise it's just a 
 static opCall :(.


The idea is that 'auto' means type inference, not RAII. To get RAII 
behavior, use A(), which invokes the constructor for A. (If A.opCall is 
called, it isn't a constructor, and so an RAII object is not created.)

The old syntax:

	auto A a = new A();

will still be supported as a deprecated feature.
Jul 26 2006
prev sibling next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 25 Jul 2006 00:53:02 -0700, Walter Bright  
<newshound digitalmars.com> wrote:

 Derek wrote:

 On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:


 And what about double meaning of 'auto'?


  In general 'auto' is a poor choice for both meanings. 'auto' is  
 obviously
 shorthand for automatic, but automatic what???  Walter, given that  
 'auto' as a keyword is not going to be removed from the
 language, how can one currently declare a type-inferred variable that  
 has
 RAII properties?


 Regan Heath penned the solution I thought I'd posted a while back, but  
 maybe I hadn't:


I recall you posting it. I'm not sure everyone saw it. I think it got lost  
in the thread.

Regan
Jul 25 2006
prev sibling next sibling parent reply Derek <derek psyc.ward> writes:
On Tue, 25 Jul 2006 00:53:02 -0700, Walter Bright wrote:


 Derek wrote:

 On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:
 

 And what about double meaning of 'auto'?


 
 In general 'auto' is a poor choice for both meanings. 'auto' is obviously
 shorthand for automatic, but automatic what??? 
 
 Walter, given that 'auto' as a keyword is not going to be removed from the
 language, how can one currently declare a type-inferred variable that has
 RAII properties?
 


 
 Regan Heath penned the solution I thought I'd posted a while back, but 
 maybe I hadn't:
 

 class A {}
 
 A a = new A(); //normal
 A a = A(); //destroyed at end of scope
 
 and with auto..
 
 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope
 
 Simple, elegant, obvious (IMO)




I'm sorry but I'm just not getting it. I just tried this example using
v0.163 and it fails to compile. I did ask "how can one *CURRENTLY* declare
...". So I guess one can't do it just now and the example is something yet
to be implemented. 

If so, it means that the opCall paradigm will be removed from classes. Is
that intentional?

And I assume that if the class was declared as ...

  auto class A {}

then every object declared with the class would have to be ..

  A a = A();
or
  auto a = A();

But how does this proposed syntax handle variable-length arrays?

  char[] a = read(filename);

Is 'a' destroyed at end of scope?

It seems to me that the implied 'destroy at end of scope' idea is not a
good one. It needs explicit designation to make it clear to readers and
coders alike. That must also help compilers in detecting coding mistakes
too.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Jul 25 2006
next sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Derek skrev:

 On Tue, 25 Jul 2006 00:53:02 -0700, Walter Bright wrote:
 

 Derek wrote:

 On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:


 And what about double meaning of 'auto'?


 In general 'auto' is a poor choice for both meanings. 'auto' is obviously
 shorthand for automatic, but automatic what??? 

 Walter, given that 'auto' as a keyword is not going to be removed from the
 language, how can one currently declare a type-inferred variable that has
 RAII properties?


 Regan Heath penned the solution I thought I'd posted a while back, but 
 maybe I hadn't:


 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO)




 
 I'm sorry but I'm just not getting it. I just tried this example using
 v0.163 and it fails to compile. I did ask "how can one *CURRENTLY* declare
 ...". So I guess one can't do it just now and the example is something yet
 to be implemented. 
 
 If so, it means that the opCall paradigm will be removed from classes. Is
 that intentional?


Walter said: "I'm hard pressed to see the point of them for classes anyway."

(http://www.digitalmars.com/d/archives/digitalmars/D/announce/1727.html)


 
 And I assume that if the class was declared as ...
 
   auto class A {}
 
 then every object declared with the class would have to be ..
 
   A a = A();
 or
   auto a = A();


I would assume so too.


 But how does this proposed syntax handle variable-length arrays?
 
   char[] a = read(filename);


I didn't even know that it is possible to make raii-dynamic arrays. :)


 Is 'a' destroyed at end of scope?


I'd say, definitely not in the above case. It seems the proposed change 
would remove the ability to declare raii dynamic arrays. The workaround 
would be:

char[] t = read(filename);
scope(exit) delete t;


 It seems to me that the implied 'destroy at end of scope' idea is not a
 good one. It needs explicit designation to make it clear to readers and
 coders alike. That must also help compilers in detecting coding mistakes
 too.


I'm vaguely agreeing. :) Something a bit more explicit would make the 
code clearer.

/Oskar
Jul 25 2006
prev sibling next sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Derek wrote:


 If so, it means that the opCall paradigm will be removed from classes. Is
 that intentional?
 
 And I assume that if the class was declared as ...
 
   auto class A {}
 
 then every object declared with the class would have to be ..
 
   A a = A();
 or
   auto a = A();
 
 But how does this proposed syntax handle variable-length arrays?
 
   char[] a = read(filename);
 
 Is 'a' destroyed at end of scope?
 
 It seems to me that the implied 'destroy at end of scope' idea is not a
 good one. It needs explicit designation to make it clear to readers and
 coders alike. That must also help compilers in detecting coding mistakes
 too.


Yes, good point. I agree.

-- 
AKhropov
Jul 25 2006
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 25 Jul 2006 21:39:29 +1000, Derek <derek psyc.ward> wrote:

 On Tue, 25 Jul 2006 00:53:02 -0700, Walter Bright wrote:


 Derek wrote:

 On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:


 And what about double meaning of 'auto'?


 In general 'auto' is a poor choice for both meanings. 'auto' is  
 obviously
 shorthand for automatic, but automatic what???

 Walter, given that 'auto' as a keyword is not going to be removed from  
 the
 language, how can one currently declare a type-inferred variable that  
 has
 RAII properties?


 Regan Heath penned the solution I thought I'd posted a while back, but
 maybe I hadn't:


 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO)




 I'm sorry but I'm just not getting it. I just tried this example using
 v0.163 and it fails to compile.


It's not yet implemented.


 I did ask "how can one *CURRENTLY* declare ...".


I was replying to Shaun when I put forward the syntax above, not you ;)


 So I guess one can't do it just now and the example is something yet to  
 be implemented.


Correct.


 If so, it means that the opCall paradigm will be removed from classes. Is
 that intentional?


My opinion is that _static_ opCall is of very limited use for classes. I  
won't miss it. Heck, my vote is for struct constructors and the removal of  
static opCall entirely.


 And I assume that if the class was declared as ...

   auto class A {}

 then every object declared with the class would have to be ..

   A a = A();
   auto a = A();


Yes. I assume it would be an error to use 'new' on an 'auto class', but, I  
don't really like the idea of 'auto class'es at all.


 But how does this proposed syntax handle variable-length arrays?

   char[] a = read(filename);

 Is 'a' destroyed at end of scope?


No.

It's my understanding that the purpose of 'auto'(destruction) is to  
guarantee a call to a class destructor, not to delete memory. After all,  
the GC will delete the array (assuming it's unreferenced) when it next  
does a collect. I think it should be illegal to apply 'auto'(destruction)  
to anything other than a class reference.

Regan
Jul 25 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Derek wrote:

 On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:


 And what about double meaning of 'auto'?


 In general 'auto' is a poor choice for both meanings. 'auto' is obviously
 shorthand for automatic, but automatic what???
 Walter, given that 'auto' as a keyword is not going to be removed from 
 the
 language, how can one currently declare a type-inferred variable that has
 RAII properties?


 
 Regan Heath penned the solution I thought I'd posted a while back, but 
 maybe I hadn't:
 

 class A {}

 A a = new A(); //normal
 A a = A(); //destroyed at end of scope

 and with auto..

 auto a = new A(); //normal
 auto a = A(); //destroyed at end of scope

 Simple, elegant, obvious (IMO) 




Yup, you had :-)

Assuming this happens, is there any chance it could be a valid syntax 
for initializing concrete types as well?  Personally, I find it quite 
useful that C++ uses the same syntax for all types, be they user-defined 
or not, as it makes for simpler template code.


Sean
Jul 25 2006
prev sibling next sibling parent David Medlock <noone nowhere.com> writes:
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
Jul 24 2006
prev sibling next sibling parent Derek <derek psyc.ward> writes:
On Sat, 22 Jul 2006 00:30:35 -0700, Walter Bright wrote:


 I think the title says it all.


There are still areas in the official documentation marked as "TBD", and so
I guess these should be done before announcing it to the (critical) world
at large.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Jul 24 2006
prev sibling next sibling parent Cris <central_p hotmail.com> writes:
And now if you focus on better class libraries, GUI, real debugger, better 
documentation, samples and  even an IDE for D \or to put it with three letters
- 
SDK\. That would be the best for the language, the technology and the users.

Why not make this SDK Open Source with a comitee of volunteers and develop it
as 
fast as possible? \Just what Project Mono does?\

Good luck!
Jul 25 2006
prev sibling parent BCS <BCS pathlink.com> writes:
Walter Bright wrote:

 I think the title says it all.


DMD 0.163 (the compiler its self)
	No

D's feature set as implemented and/or documented with DMD 0.163
	Yes (reluctantly)

D's specs as documented with 0.163
	No

Phobos 0.163 (and all the other libs)
	No

We can go with the features we have, some of them need to be tweaked a 
bit though.

The spec it's self needs some editing/elaboration/etc.

The libs _may_ need a total rewrite.

Also DMD will need few months of bug work after the D spec v1.0 is cut 
into a stone tablet. (But those bug fixes could get numbered 1.0.x for 
all I care.)
Jul 25 2006