janderson wrote:
> David B. Held wrote:
>> Ameer Armaly wrote:
>>> Hi all. There are a few things which have been bothering me as of late, and I want your opinions on them to know whether or not I'm jumping at shadows. For starters, we all have a common goal of making D as widely used as possible since we all love the language, otherwise we probably wouldn't be here. At the same time, there are a few factors which as I see it make the adoption of D much more difficult and need to be addressed if we intend to succeed:
>>> [...]
>>
>> I think one thing to keep in mind is that the 1.0 release was basically a gift to the user community to lend D that air of authenticity that business folks need to let their people use a new toy.  In reality, there are so many radical features being considered for D that it's really comparable to C++ in its CFront stage rather than the ARM, let alone, ANSI stage.  On the one hand, D needs users to push the language to expose its weaknesses.  On the other hand, D needs the flexibility to break some stuff to add compelling new features.  It's a tricky business bootstrapping a new language, and only people who can tolerate life on the bleeding edge survive in this kind of space.
>>
>> D does indeed need a fair bit of time before it becomes sufficiently stable to consider something like standardization.  Even choosing a standard library would be premature, given that D has nothing like the STL yet, though something is planned.  And having a wealth of choices isn't a bad thing.  If functionality grossly overlapped, that would be one thing.  But by providing libraries with different design philosophies to appeal to different user segments, D can ease the transition for more programmers.  If anything, now is the time to think hard about what you think a language should have, and make a strong case for your favorite features.  There's no guarantee your feature will get implemented, but look how hard it is to get something added to a language as big and mature as C++...
>>
>> Dave
> 
> I couldn't have put it better!

Academic wise 1.0 is a good thing because you want people to be able to compile and run your algorithms.  For instance, my pre 1v thesis source code will no-longer compile because a couple of the D libraries I was using broke.  Luckily I have a version of the compiler that did work however foolishly I forgot to mention which version.

-Joel

Peter C. Chapin wrote:
> [...]
> Ideally once 1.0 was released there should have been a fork in the release schedule for D. Bug fixes to 1.0 could be provided separately from language enhancements leading toward 2.0 (or whatever). That way people interested in coding to the 1.0 "standard" could get a fixed compiler without the "clutter" of new features.
> [...]

This is a pretty important point, and more people should complain about this.  It does dilute the utility of having a 1.0 release.

Dave

"David B. Held" <dheld@codelogicconsulting.com> wrote in news:evbaso$2jlr$1@digitalmars.com:

>> Ideally once 1.0 was released there should have been a fork in the release schedule for D. Bug fixes to 1.0 could be provided separately from language enhancements leading toward 2.0 (or whatever). That way people interested in coding to the 1.0 "standard" could get a fixed compiler without the "clutter" of new features.
> 
> This is a pretty important point, and more people should complain about this.  It does dilute the utility of having a 1.0 release.

Perhaps the v1 switch mentioned in another post addresses this. I imagine that v1 does not turn on old bugs. Is the latest documentation clear about what features are in version one and what features have been added or changed since?

Perhaps it's time for me to upgrade. :-) It looks like there have been quite a few bug fixes.

Peter

Peter C. Chapin wrote:
> "David B. Held" <dheld@codelogicconsulting.com> wrote in news:evbaso$2jlr$1@digitalmars.com:
> 
>>> Ideally once 1.0 was released there should have been a fork in the release schedule for D. Bug fixes to 1.0 could be provided separately from language enhancements leading toward 2.0 (or whatever). That way people interested in coding to the 1.0 "standard" could get a fixed compiler without the "clutter" of new features.
>> This is a pretty important point, and more people should complain about this.  It does dilute the utility of having a 1.0 release.
> 
> Perhaps the v1 switch mentioned in another post addresses this. I imagine that v1 does not turn on old bugs. Is the latest documentation clear about what features are in version one and what features have been added or changed since?
> 
> Perhaps it's time for me to upgrade. :-) It looks like there have been quite a few bug fixes.
> 
> Peter

As far as I understand it, throwing -v1 disables any features that would change the meaning of your code, and changes the GC back to its v1.0 behaviour.

However, the caveat here is that it does *not* disable features that don't change the meaning of your code.  For instance, compile-time function evaluation was added post-1.0, but is not affected by -v1.  The reasoning behind this is that CTFE allows you to use non-constant expressions where you previously couldn't.  Ergo, if your code was written for v1.0, then it couldn't have had any of these expressions, thus it doesn't change anything.

Or something like that :)  However, I do think that the D docs should explicitly mark things that have changed since 1.0, possibly even adding a strict version of -v1 that completely disallows new features so that people can use the latest compilers to write v1.0-compatible code (and actually make sure that it will work!).

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Clay Smith wrote:
> I'm just a hobbyer, but I care about the D v1.0 version switch. 
> 
> This switch makes it so any compiler after version 1.0 can compile my programs, and anyone who writes a D 1.0 compatible compiler can also compile my programs. D 1.0 is a nice 'target' that doesn't move. To be able to ever stabilize, a language needs such a target or it will forever be left for the bleeding edgers.
> 
> ~ Clay
> 
> Bruno Medeiros Wrote:
>> Indeed. Aside publicity/marketing, does D 1.0 even matter at all? By "matter", I mean, who of the D developers (even if just hobbying around) use, work with, or generally care about D 1.0 instead of the current D? Likely few or none, especially with the amazing new features added, and even more are planned to come.
>>
>>
>> -- 
>> Bruno Medeiros - MSc in CS/E student
>> http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
> 

Yes, I know what the switch allows, but I'm wondering who is actually using it.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

David B. Held wrote:
> Peter C. Chapin wrote:
> 
>> [...]
>> Ideally once 1.0 was released there should have been a fork in the release schedule for D. Bug fixes to 1.0 could be provided separately from language enhancements leading toward 2.0 (or whatever). That way people interested in coding to the 1.0 "standard" could get a fixed compiler without the "clutter" of new features.
> 
> This is a pretty important point, and more people should complain about this.  It does dilute the utility of having a 1.0 release.

There should also be a clear separation in the documentation!!

The D documentation doesn't seem to care what things are 1.0 and what "post-1.0". Imagine a programming team trying to conform to 1.0. While the compiler can of course barf on too-new things, the programmers have a hard time learning what is and what isn't 1.0.

Of course, we could deliver two separate html trees with DMD, but obviously the bloat is unacceptable.

Therefore, IMHO, the second-best would be to have the 1.0 html as a separate zip, downloadable from DM, -- and adequately advertise it on the site.


To help the programming teams in not reading the wrong version (1.0 vs. the current), the downloadable 1.0 should have a pale yellow background color, as in old paper. Then, e.g. somebody just quickly glancing at a colleagues screen (say, to help him understand something), it would stand clearly out whether we are looking at 1.0 or the current doc.

All it takes is to change dmd/html/d/style.css on the third line from

  background: white;

to

  background: #ffffc0;

and zip the 1.0 html to the server.


Oh, and of course the *current* doc shoud mention the 1.0 docs being available.

---

I wanted to keep this *simple enough to actually become reality now*, given Walter's limited time. Obviously a better solution (and one that we'll eventually need) would be to have the background with a pale yellow D-1.0 watermark-like text, but first things first!

Bruno Medeiros wrote:
<snip>
>> Bruno Medeiros Wrote:
>>> Indeed. Aside publicity/marketing, does D 1.0 even matter at all? By "matter", I mean, who of the D developers (even if just hobbying around) use, work with, or generally care about D 1.0 instead of the current D? Likely few or none, especially with the amazing new features added, and even more are planned to come.
>>>
<snip>
> Yes, I know what the switch allows, but I'm wondering who is actually using it.
> 

I have a dwt app that uses it, and the dallegro project uses it too. It's mostly a C binding.  I guess one problem is that it makes it more complicated for users of dallegro to use backwards compatibility breaking features.  They would have to compile the dallegro files separately from files that use post-1.0-only features.  So I guess a 'D_1_0' version ID would be useful.  Or some other system that allows libraries to adjust to being built both with and without -v1.  Then the compatibility issue could be handled in a way that's transparent to the user.

I haven't looked into both DMD and GDC's versions of std.compiler, so I don't know how far that would take you.  And then there's Tango.  But this should really be part of the compiler, not of the library.

Daniel Keep <daniel.keep.lists@gmail.com> wrote in news:evd7k4$1759$1 @digitalmars.com:

> However, the caveat here is that it does *not* disable features that don't change the meaning of your code.  For instance, compile-time function evaluation was added post-1.0, but is not affected by -v1.  The reasoning behind this is that CTFE allows you to use non-constant expressions where you previously couldn't.  Ergo, if your code was written for v1.0, then it couldn't have had any of these expressions, thus it doesn't change anything.

Hmm. That's great for existing 1.0 code that is compiled with the newer compiler but, as you point out, not so good for people developing new code and who wish to conform to the 1.0 definition of the language. I wouldn't want the compiler to accept a feature that was post-1.0 that I accidently used.

Peter