== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Tomas Lindquist Olsen wrote:
> > On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> >> Denis Koroskin wrote:
> >>> One of the breaking changes that I recall was that you made Posix identifier built-in and thus any custom Posix versioning became an error. Not sure if it was introduced in 1.041, though, but it is still a breaking change.
> >> It was more of a build system change, but I get your point. It shows that even trivial changes are a bad idea for D1.
> >>
> >
> > Everyone certainly does not think it was a bad idea. If trivial things like this sets people off, they should at least look at the problem (and comment those few lines) before complaining.
> >
> > All my humble opinion of course.
> To me, it illustrates a fundamental disconnect. One cannot have both a
> 100% stable language and yet introduce improvements to it.
> As for the does one develop stable code targeting D1 and D2, I would
> suggest targeting D1 but be careful to use the string alias for all the
> char[]'s, and treat strings as if they were immutable. This will cover
> 90% of any source code changes between D1 and D2, perhaps even more than
> 90%. It's also very possible to write D1 code using the immutability
> style, in fact, I advocated it long before D2 (see all the old threads
> discussing Copy On Write). If code follows the COW principle, it should
> port from D1 to D2 with little more than a few cosmetic changes.

One minor thing in druntime that may help is that opEquals() returns
an equals_t, which evaluates to bool in D2.  It would probably be worth
changing the declaration in D1 to have a similar alias that evaluates to
int.  That should help address another minor inconsistency between D1
and D2.

On Thu, 26 Mar 2009 15:50:22 -0400, Brad Roberts <braddr@puremagic.com> wrote:

> Steven Schveighoffer wrote:
>> On Thu, 26 Mar 2009 07:42:01 -0400, Mike James <foo@bar.com> wrote:
>>
>>> Is Tango for D2.0 at a level of D1.0 and can be used now?
>>
>> No.  It is being worked on.  I don't forsee Tango for D2 being ready
>> until at least September, perhaps later.
>>
>> -Steve
>
> Would you mind outlining / documenting what needs to be done?  I'd
> expect that there are a number of people who would be interested in
> volunteering to help.

what needs to be done:

1. Make Tango build on top of druntime.  I just merged from trunk yesterday, which was about 300 files, so most likely there will be compile issues ;)
2. Const-ify everything.  Some parts are already done.
3. Make all opApply's scoped properly.

Not sure what happens after that, but step 2 alone is a ton of work.  In addition, there are some blocker bugs in DMD (1645 and 2524 right now) that prevent a complete port.

When the shared/unshared paradigm is released, there's probably another ton of work to do :)

And of course, there's the possibility of redesigns.  A lot of code can probably make use of __traits and there are the new range constructs to consider.  Of course, these are all probably things that would be severely different from the D1 version, so they probably won't happen for a while.

Note that the September or later date is based on the amount of time I spend on it (which isn't a lot).  Someone who wanted to do nothing but porting Tango to D2 could probably get it done in a month or two.  Note also that I don't consider the port done until all the "cast to get it to compile" hacks are removed.  In some cases, this requires design changes, and in some of those, tough decisions.

-Steve

On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Tomas Lindquist Olsen wrote:
>>
>> On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright <newshound1@digitalmars.com> wrote:
>>>
>>> Denis Koroskin wrote:
>>>>
>>>> One of the breaking changes that I recall was that you made Posix identifier built-in and thus any custom Posix versioning became an error. Not sure if it was introduced in 1.041, though, but it is still a breaking change.
>>>
>>> It was more of a build system change, but I get your point. It shows that even trivial changes are a bad idea for D1.
>>>
>>
>> Everyone certainly does not think it was a bad idea. If trivial things like this sets people off, they should at least look at the problem (and comment those few lines) before complaining.
>>
>> All my humble opinion of course.
>
> To me, it illustrates a fundamental disconnect. One cannot have both a 100% stable language and yet introduce improvements to it.
>

I don't necessarily want a 100% stable language. In fact I don't. But
obviously asking for both is just silly.
The only thing I'm not happy about is if code that used to work, still
compiles, but no longer works. This is where the real problem is and
I've seen it several times. MinWin, APaGeD and probably others.

On Thu, Mar 26, 2009 at 9:25 PM, Tomas Lindquist Olsen <tomas.l.olsen@gmail.com> wrote:
> On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright <newshound1@digitalmars.com> wrote:
>> Tomas Lindquist Olsen wrote:
>>>
>>> On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright <newshound1@digitalmars.com> wrote:
>>>>
>>>> Denis Koroskin wrote:
>>>>>
>>>>> One of the breaking changes that I recall was that you made Posix identifier built-in and thus any custom Posix versioning became an error. Not sure if it was introduced in 1.041, though, but it is still a breaking change.
>>>>
>>>> It was more of a build system change, but I get your point. It shows that even trivial changes are a bad idea for D1.
>>>>
>>>
>>> Everyone certainly does not think it was a bad idea. If trivial things like this sets people off, they should at least look at the problem (and comment those few lines) before complaining.
>>>
>>> All my humble opinion of course.
>>
>> To me, it illustrates a fundamental disconnect. One cannot have both a 100% stable language and yet introduce improvements to it.
>>
>
> I don't necessarily want a 100% stable language. In fact I don't. But
> obviously asking for both is just silly.
> The only thing I'm not happy about is if code that used to work, still
> compiles, but no longer works. This is where the real problem is and
> I've seen it several times. MinWin, APaGeD and probably others.
>

Which leads me to: If I was to help with a D 1.1 implementation, only features that would not change any semantics of valid D1 code would go in.

Tomas Lindquist Olsen wrote:
> On Thu, Mar 26, 2009 at 9:25 PM, Tomas Lindquist Olsen
> <tomas.l.olsen@gmail.com> wrote:
>> On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>> Tomas Lindquist Olsen wrote:
>>>> On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
>>>> <newshound1@digitalmars.com> wrote:
>>>>> Denis Koroskin wrote:
>>>>>> One of the breaking changes that I recall was that you made Posix
>>>>>> identifier built-in and thus any custom Posix versioning became an
>>>>>> error. Not sure if it was introduced in 1.041, though, but it is
>>>>>> still a breaking change.
>>>>> It was more of a build system change, but I get your point. It shows that
>>>>> even trivial changes are a bad idea for D1.
>>>>>
>>>> Everyone certainly does not think it was a bad idea. If trivial things
>>>> like this sets people off, they should at least look at the problem
>>>> (and comment those few lines) before complaining.
>>>>
>>>> All my humble opinion of course.
>>> To me, it illustrates a fundamental disconnect. One cannot have both a 100%
>>> stable language and yet introduce improvements to it.
>>>
>> I don't necessarily want a 100% stable language. In fact I don't. But
>> obviously asking for both is just silly.
>> The only thing I'm not happy about is if code that used to work, still
>> compiles, but no longer works. This is where the real problem is and
>> I've seen it several times. MinWin, APaGeD and probably others.
>>
> 
> Which leads me to: If I was to help with a D 1.1 implementation, only
> features that would not change any semantics of valid D1 code would go
> in.

Isn't this the point of the whole "D 1.1" idea?

Tomas Lindquist Olsen wrote:
> Which leads me to: If I was to help with a D 1.1 implementation, only
> features that would not change any semantics of valid D1 code would go
> in.

But they always do. Many of the complaints about D1 breaking things is the result of bug fixes to D1 inadvertently breaking something unexpected.

Tomas Lindquist Olsen wrote:
> I don't necessarily want a 100% stable language. In fact I don't. But
> obviously asking for both is just silly.
> The only thing I'm not happy about is if code that used to work, still
> compiles, but no longer works. This is where the real problem is and
> I've seen it several times. MinWin, APaGeD and probably others.

What do you suggest?

It's why there's a "last stable version" of D1 on the website. With any software package, if you always download the latest version but another package was only tested with a different version, it's likely to have problems.

Tomas Lindquist Olsen wrote:
> D1 does have some missing features that are in D2, and could be
> backported to D1 without breaking any code.
> This isn't going to happen for the sake of stability. But if I want to
> use some of the new features, I have to get all the cruft that made me
> look into D in the first place as well. A major reason I started with
> D was because of simple syntax, GC and lack of the const hell.
> 
> D2 is no longer a simple language, you have to know all kinds of shit
> to be able to use it correctly.
> 
> All my projects at the moment are in C++. And TBH I don't see that
> changing any time soon. The stuff I did in D no longer works, and I
> don't have time to debug the entire thing to figure out how/where the
> compiler changed.

I've worked with C/C++ for decades, and it's a miracle if code that compiled 10 years ago compiles today without changes. Code never works without changes when porting to a different compiler. Code targeted at VC tends to target specific versions of VC. "Portable" libraries like Boost, STL, and Hans Boehm GC are full of #ifdef's.

The only real difference from D is that:
1. The evolution of C++ is about 10 times slower than D.
2. We're all so used to working around these problems in C++, we don't notice it.

I understand your frustrations with the changes, just not why that means using C++ <g>.

> And yes, the Phobos vs. Tango (which in turn keeps breaking) situation
> of course isn't making things better.

Steven Schveighoffer wrote:
> what needs to be done:
> 
> 1. Make Tango build on top of druntime.  I just merged from trunk yesterday, which was about 300 files, so most likely there will be compile issues ;)
> 2. Const-ify everything.  Some parts are already done.
> 3. Make all opApply's scoped properly.
> 
> Not sure what happens after that, but step 2 alone is a ton of work.  In addition, there are some blocker bugs in DMD (1645 and 2524 right now) that prevent a complete port.
> 
> When the shared/unshared paradigm is released, there's probably another ton of work to do :)

You can already used shared/unshared. The semantics aren't implemented, but the type system support for it is.

> 
> And of course, there's the possibility of redesigns.  A lot of code can probably make use of __traits and there are the new range constructs to consider.  Of course, these are all probably things that would be severely different from the D1 version, so they probably won't happen for a while.
> 
> Note that the September or later date is based on the amount of time I spend on it (which isn't a lot).  Someone who wanted to do nothing but porting Tango to D2 could probably get it done in a month or two.  Note also that I don't consider the port done until all the "cast to get it to compile" hacks are removed.  In some cases, this requires design changes, and in some of those, tough decisions.
> 
> -Steve

On Thu, Mar 26, 2009 at 9:45 PM, grauzone <none@example.net> wrote:
> Tomas Lindquist Olsen wrote:
>>
>> Which leads me to: If I was to help with a D 1.1 implementation, only features that would not change any semantics of valid D1 code would go in.
>
> Isn't this the point of the whole "D 1.1" idea?
>

People seem to have different ideas of what D 1.1 should be.