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 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
prev sibling next sibling 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).

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. A few more bug fixes would be nice (#146) but those can be done after 1.0. More time for the new imports, sure, but no new features! Let's do this already! -- ~John Demme me teqdruid.com http://www.teqdruid.com/
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 1.0. A few more bug fixes would be nice (#146) but those can be done after 1.0. More time for the new imports, sure, but no new features! Let's do this already! -- ~John Demme me teqdruid.com http://www.teqdruid.com/

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 1.0. A few more bug fixes would be nice (#146) but those can be done after 1.0. More time for the new imports, sure, but no new features! Let's do this already! -- ~John Demme me teqdruid.com http://www.teqdruid.com/


-- ~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. A few more bug fixes would be nice (#146) but those can be done after 1.0. More time for the new imports, sure, but no new features! Let's do this already!

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.

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 C#/Java, I think D is better in every way except for _standard_ library 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 into one place so that they can rival Java/C#. This needs organization 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

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: # T[] array (T) (T[] args ...) { return args.dup; } # # int foo = array!(int)(1, 2, 3); 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: 
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: 
 digitalmars.D/38443
 
 (I personally vote for 'var' for type inference)
 

Agreed, and I've caught myself more than once starting to type this "auto auto" mess. And I also agree with "var" as a good choice for doing this. I'm already used to using "var" in other platforms, including PHP, ECMAScript, and my own Bovis language. ##### PHP # class Foo { # var $someField = 42 ; # } ##### ECMAScript # var x = 27 ; ##### Bovis # var 'Any $foo = 99 ; // the 'Any specifier is optional, of course And I believe this is what is used in the new edition of C# for type inference, yes? (I haven't touched C# since the 1.0 so someone let me know if I'm wrong.) Precedence has been established for it. It shouldn't be un-intuitive to many people. -- Chris Nicholson-Sauls
Jul 23 2006
next sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Chris Nicholson-Sauls wrote:

 And I believe this is what is used in the new edition of C# for type
 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:
 
 And I believe this is what is used in the new edition of C# for type 
 inference, yes?

Yes, though 'auto' will be used for type inference in C++. Personally, I'd prefer scoped destruction to use a keyword such as 'local' or 'scoped' than to change the keyword used for type inference. Sean
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:
  And I believe this is what is used in the new edition of C# for type  
 inference, yes?

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

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:
  And I believe this is what is used in the new edition of C# for type 
 inference, yes?

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

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:
  And I believe this is what is used in the new edition of C# for 
 type inference, yes?

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

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:
  And I believe this is what is used in the new edition of C# for  
 type inference, yes?

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

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:
  And I believe this is what is used in the new edition of C# for 
 type inference, yes?

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

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: 
 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: 
 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: 
 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. Rule#23: Dealing with Identifier Names. [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.
 Rule#23: Dealing with Identifier Names.
 [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.

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:

 Rule#23: Dealing with Identifier Names.


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 languages (JavaScript, C# 3.0, Scala...) for this purpose. 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 languages (JavaScript, C# 3.0, Scala...) for this purpose. 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)


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'?

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'?

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?

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