Bill Baxter wrote:
> Currently as we all know, D1 gets no new features, and D2 is a crazy rocketship that could change direction at any moment.
> 
> Now I know a lot of people were asking for D to become more stable pre D1 days, but is this really what you wanted?

I appreciate the fact that D1 is stable. But it seems a bit too "stable" (as in not moving) to me, somehow. AFAIK, there are still a lot of long-standing bugs around, the toolchain is still kind of immature and/or outdated. I understand that Walter as a single person can't possibly reimplement parts of the toolchain while maintaining the compilers, but then again, what about delegation?

The D community has shown to be a bunch of pretty (very) knowledgable people. A little delegation here and there would get Walter some time to work on new features and the community some opportunity to properly polish D1 with all its tools.

Another thing I'm eager for is a reimplementation of the D1 reference compiler in D1 (DMD D1). This would be a huge step forward for D, besides from Walter actually using D. The toolchain still feels somewhat like a prototype to me..

(Out of interest: how hard would it be to plug a D frontend to the current DMD backend? Would it even be possible?)

Kris wrote:
> As one of the early proponents of const (actually, a subset of const), I have to admit to being disappointed with the current D2 mechanisms. Have avoided commentry in the past, because D2 has been positioned as merely experimental. However, from what I understand, Walter is feeling like the const design is almost baked.

That's right, although there have been bugs in the implementation (many were fixed in the 2.012 update).

> My original beef was not being able to protect a return value (such as a char[]) from being abused without having to copy the returned content instead of returning a slice. At the time, the 'in' modifier provided suitable intent and control for read-only parameters, so the /hope/ was for something reasonbly simple (to the user) in order to handle the return-value aspect.

If you ever find yourself needing to dup an invariant array, there's a bug somewhere else in the code.

> While I understand how things can sometimes quickly become complex while trying to support a simple notion, there's nothing trivial at all about using or comprehending the D2 const mechanisms. A claim has been made that one does not have to use or be aware of const or invariant to use D2 ... unfortunately that does not appear to be the case in practice, and the added complexity makes D2 harder to work with than D1.

In some ways it is more complex, but in other ways it is simpler. Not the language, but the way it is used. For instance, you shouldn't have to be worrying about defensively duping invariant arrays.

"Walter Bright" <newshound1@digitalmars.com> wrote
> Kris wrote:
>> While I understand how things can sometimes quickly become complex while trying to support a simple notion, there's nothing trivial at all about using or comprehending the D2 const mechanisms. A claim has been made that one does not have to use or be aware of const or invariant to use D2 ... unfortunately that does not appear to be the case in practice, and the added complexity makes D2 harder to work with than D1.
>
> In some ways it is more complex, but in other ways it is simpler. Not the language, but the way it is used. For instance, you shouldn't have to be worrying about defensively duping invariant arrays.

It is simpler and generally more effective to design an API which avoids the .dup issue. Thus, IMO, const and invariant typically have little value for well over 90% of engineering with D, assuming 'in' remains as always. Yeah, I'm aware of and appreciate the potential benefits involved, both large and small and in their various guises for current and future goodies within D ... but the usage is currently not sufficiently transparent.

Usage of dup (and idup) is not a good poster-child to hold aloft, when they can be avoided in the vast majority of cases. For example, in all of Tango there's only one instance where a const return would be nice to have, due mostly to an avoidance of the situation. The usage of  D1 'in' can suffice for all read-only parameters. Tango is a large body of code, as you know, with attention given to efficiency. One might hope the highly narrow scope therein for D2 const/invariant might indicate something of value for you -- perhaps that const/invariant might slip into a "special consideration" usage instead? If it simplified the syntax and/or usage, a lot of people would be jumping into D2 instead of remaining with D1

What I'm saying is effectively this: you don't have to solve all the const cases to still have a stupidly-effective language. The tradeoffs to get there so far are, imo, too costly in areas of comprehension and usability - two huge factors in the attraction of D in the first place. Some folks might disagree, and that's cool.

It would be interesting to draw a graph plotting "degree of involvement in large-scale D engineering" versus "perceived complexity/value tradeoff regarding const"

2c

Kris wrote:
> It is simpler and generally more effective to design an API which avoids the .dup issue.

But you shouldn't *need* to be doing .dup for invariant arrays. If you are duping them, there's a problem somewhere else in the code.

> Usage of dup (and idup) is not a good poster-child to hold aloft, when they can be avoided in the vast majority of cases. For example, in all of Tango there's only one instance where a const return would be nice to have, due mostly to an avoidance of the situation. The usage of  D1 'in' can suffice for all read-only parameters. Tango is a large body of code, as you know, with attention given to efficiency. One might hope the highly narrow scope therein for D2 const/invariant might indicate something of value for you --  perhaps that const/invariant might slip into a "special consideration" usage instead? If it simplified the syntax and/or usage, a lot of people would be jumping into D2 instead of remaining with D1

You can write bug-free and perfectly correct programs without const or invariant at all. But once a code base exceeds a certain level of size and complexity (and I don't know what that level is), const/invariant will become increasingly valuable. People who do work in large corporations managing extremely large codebases with legions of programmers working on them have made this abundantly clear to me.

> What I'm saying is effectively this: you don't have to solve all the const cases to still have a stupidly-effective language. The tradeoffs to get there so far are, imo, too costly in areas of comprehension and usability - two huge factors in the attraction of D in the first place. Some folks might disagree, and that's cool.

Part of the problem with const/invariant in D is we burned a lot of goodwill with the two previous designs that fell short of the mark. But I believe the design now is a sound one (despite the bugs in implementing some of the details, many of which were fixed in the latest update).

Walter Bright wrote:
> You can write bug-free and perfectly correct programs without const or invariant at all. But once a code base exceeds a certain level of size and complexity (and I don't know what that level is), const/invariant will become increasingly valuable. People who do work in large corporations managing extremely large codebases with legions of programmers working on them have made this abundantly clear to me.

Yes, they believe they need it.  Sure.  But I doubt many of them have done any sort of analysis of how much it actually helps vs. how much it complicates their code base.  I say this as someone who was totally sold on C++ const for the first 10 years I used it.

Now I'm kind of used to not having it.  And, well, the sky hasn't fallen.  But lots of my code has lost superfluous redundancy.

But I'm going to start trying to compile my code with D2 this weekend and see how it goes.  Hopefully const will mostly stay out of my way.

--bb

"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:fqq8ps$g0r$1@digitalmars.com...
> Currently as we all know, D1 gets no new features, and D2 is a crazy rocketship that could change direction at any moment.
>
> Now I know a lot of people were asking for D to become more stable pre D1 days, but is this really what you wanted?
>
> I had initially assumed that the freeze on D1 was at least as much due to time constraints on Walter as it was due to a desire for stability. But in a recent message Walter said that wasn't the case.  He said that backporting things from D2 to D1 was pretty trivial.
>
> So really then, it to comes down to Walter believing that the D community wants D1 to be feature frozen.
>
> Is it really true?  Is there a group of folks who really want D1 to be frozen?
>
IMO it's not so much a case of wanting D1 to be frozen but wanting D1 to become more polished I.E. instead of trying to backport new language features, we should try and move towards some kind of consensus regarding standard libraries. Once D1 doesn't appear to have EXPERIMENTAL written all over it then backporting non-breaking features might be viable.
> I myself would like to see D1 get all new features that won't break existing source code.
>
> Things like:
> * New string literals
>   - q{a=b} D-token string syntax,
>   - delimited strings, q"(...)"
>   - heredocs, q"EOF...
> * IFTI that works even if you specify one parameter,
> * Enhanced is expression
>   - is ( Type Identifier : TypeSpecialization , TemplateParameterList )
>   - is ( Type Identifier == TypeSpecialization , TemplateParameterList )
> * foreach(i; 0..10) syntax (ForeachRangeLiteral)
> * Overload sets
>
>
> I'm all with the sentiment that D1 code that compiles today should compile tomorrow.  That kind of stability is great.  But if it's not a big time commitment for Walter (which he says it's not), I see no good reason to keep new backwards-compatible features out of D1.
>
> I've heard other folks saying they want this from D1 too, but what I haven't heard is a great swell of active D developers saying that new features would be a detriment to their work.
>
> --bb,
> (who has now written and/or ported about 200,000 lines of D according to a
> quick check with 'wc')

Bill Baxter wrote:
> Currently as we all know, D1 gets no new features, and D2 is a crazy rocketship that could change direction at any moment.
> 
> Now I know a lot of people were asking for D to become more stable pre D1 days, but is this really what you wanted?
> 
> I had initially assumed that the freeze on D1 was at least as much due to time constraints on Walter as it was due to a desire for stability. But in a recent message Walter said that wasn't the case.  He said that backporting things from D2 to D1 was pretty trivial.
> 
> So really then, it to comes down to Walter believing that the D community wants D1 to be feature frozen.
> 
> Is it really true?  Is there a group of folks who really want D1 to be frozen?
> 
> I myself would like to see D1 get all new features that won't break existing source code.
> 
> Things like:
> * New string literals
>   - q{a=b} D-token string syntax,
>   - delimited strings, q"(...)"
>   - heredocs, q"EOF...
> * IFTI that works even if you specify one parameter,
> * Enhanced is expression
>   - is ( Type Identifier : TypeSpecialization , TemplateParameterList )
>   - is ( Type Identifier == TypeSpecialization , TemplateParameterList )
> * foreach(i; 0..10) syntax (ForeachRangeLiteral)
> * Overload sets
> 
> 
> I'm all with the sentiment that D1 code that compiles today should compile tomorrow.  That kind of stability is great.  But if it's not a big time commitment for Walter (which he says it's not), I see no good reason to keep new backwards-compatible features out of D1.
> 
> I've heard other folks saying they want this from D1 too, but what I haven't heard is a great swell of active D developers saying that new features would be a detriment to their work.

I disagree that new features in D2 should be backported.

I am a newbie to D and what I think D1 needs is for any bugs to be fixed and for the documentation to be improved in that it needs to be more expansive so that end users understand how to use the language. Right now the docs are still very sparse and not easy to understand.

Essentially D1 needs to be made as solid as possible for end users. Keeping it in flux is not a good way to attract people to D. One always needs a release of a language that people can use with confidence.

When D2 is finally finished, it needs to be treated the same. Fix bugs and update the documentation to be better, so it can be used more easily and understood. Have all new features beyond it go in a new version.

Endlessly making changes to a language for each and every release is not, repeat not, a good way to get people to use that language and its libraries in a serious way in order to write modules and applications.

Bill Baxter wrote:
> Currently as we all know, D1 gets no new features, and D2 is a crazy rocketship that could change direction at any moment.

I'm not opposed to having D1 get back-ported features (provided, of course, that they are backward compatible).  However, I'm concerned about the workload on Walter.  If he spends too much time on D1, D2 won't get the attention it deserves.

If all the changes are non breaking ones and if it doesn't take any significant time to port them, why then are people still against it?

Why does everybody keep pointing out that other things need fixing.
That is irrelevant, if porting the extra feature to D1 won't take any time.

I would applaud any feature coming to the stable D1 branch.
Everybody should be warned that D2 might break at any release, but D1 can
safely be used and when lucky it will even be improved without breaking
older D1 code (its like giving away presents).

>
> I disagree that new features in D2 should be backported.
>
> I am a newbie to D and what I think D1 needs is for any bugs to be fixed and for the documentation to be improved in that it needs to be more expansive so that end users understand how to use the language. Right now the docs are still very sparse and not easy to understand.
>
> Essentially D1 needs to be made as solid as possible for end users. Keeping it in flux is not a good way to attract people to D. One always needs a release of a language that people can use with confidence.
>
> When D2 is finally finished, it needs to be treated the same. Fix bugs and update the documentation to be better, so it can be used more easily and understood. Have all new features beyond it go in a new version.
>
> Endlessly making changes to a language for each and every release is not, repeat not, a good way to get people to use that language and its libraries in a serious way in order to write modules and applications.

Saaa pisze:
> If all the changes are non breaking ones and if it doesn't take any significant time to port them, why then are people still against it?
> 
> Why does everybody keep pointing out that other things need fixing.
> That is irrelevant, if porting the extra feature to D1 won't take any time.
> 
> I would applaud any feature coming to the stable D1 branch.
> Everybody should be warned that D2 might break at any release, but D1 can safely be used and when lucky it will even be improved without breaking older D1 code (its like giving away presents).


I see two important problems with backporting new features from D 2.0 into D 1.0 branch:

1. Porting bigger chunks of code can introduce new bugs into 1.0 branch. Please note that 2.0 is not tested as well as 1.0, so it is more than probable that it will happen. Also it is possible that some of new features can interact with other features (old or new ones) so it will make porting a headache: you will always have to think what should be ported to make the whole thing working in 1.0.

2. Semantics of new features in D 2.0 branch can change until 3.0 branch will be crated. It basically means that, when new features will be continuously ported to D 1.0, then 1.0 branch will no more be stable. You will not be able to create any program in D 1.0 (using new features) and be sure that it won't break in future, because this features can be changed later.

In my opinion there is not much sense in porting 2.0 compiler features into 1.0 branch. Also creating branch 1.5 does not make much sense for me. If I would like to use all new features of D, I would just use 2.0 branch. That said, I really appreciate effort of porting Phobos 2.0 into 1.0 (std2 project in dsource). Some of new features of Phobos 2.0 are really useful, and Phobos 1.0 badly lacks them.

Best Regards
Marcin Kuszczak
(aarti_pl)