Reiner Pope wrote:
> Perhaps you mean that you can write
> 
> void Foo(T)(T* t) { ... }
> ...
> int x;
> Foo(&x);
> 
> Sure. But the following doesn't work:
> 
> void Foo(T)(T t) { ... }
> void Foo(T)(T* t) { /* different implementation for this specialisation  */ }
> ...
> int x;
> Foo(x);
> Foo(&x); // ambiguous
> 
> and using template parameter specialisation, IFTI breaks.

You can write the templates as:

void Foo(T)(T t) { ... }
void Foo(T, dummy=void)(T* t) { /* different implementation for this specialisation
 */ }

Not so pretty, but it works.


> As to complicated predicates, I refer to the common idiom in D templates which looks like the following:

Sean Kelly had a solution for that of the form:

> More often, I use an additional value parameter to specialize against:
> 
> template Foo(T, bool isValid : true = PassesSomeTest!(T)) {}

eao197 wrote:
> I know that you work very hard on D, but D 1.0 took almost 7 years. D 2.0 started in 2007, so final D 2.0 could be in 2014?

It's very amusing to read how Walter described D 1.0, seven years ago. It wasn't going to have templates, for example.

On Wed, 29 Aug 2007 15:56:29 +0400, Don Clugston <dac@nospam.com.au> wrote:

> eao197 wrote:
>> I know that you work very hard on D, but D 1.0 took almost 7 years. D 2.0 started in 2007, so final D 2.0 could be in 2014?
>
> It's very amusing to read how Walter described D 1.0, seven years ago. It wasn't going to have templates, for example.

Unfortunately I see to D's evolution, perhabs, from 2002 or 2003 year. It looks as D have never been a stable language.

-- 
Regards,
Yauheni Akhotnikau

eao197 wrote:
> Unfortunately I see to D's evolution, perhabs, from 2002 or 2003 year. It looks as D have never been a stable language.


I don't know any language in wide use that is stable (i.e. not changing). A stable language is a dead language.

Walter Bright wrote:
> eao197 wrote:
>> Unfortunately I see to D's evolution, perhabs, from 2002 or 2003 year. It looks as D have never been a stable language.
> 
> 
> I don't know any language in wide use that is stable (i.e. not changing). A stable language is a dead language.

I guess there's "stable" and there's "stable"? The history of Simula67 illustrates what can happen when a language is nailed to the wall :)

On Wed, 29 Aug 2007 23:15:26 +0400, Walter Bright <newshound1@digitalmars.com> wrote:

> eao197 wrote:
>> Unfortunately I see to D's evolution, perhabs, from 2002 or 2003 year. It looks as D have never been a stable language.
>
>
> I don't know any language in wide use that is stable (i.e. not changing). A stable language is a dead language.

I mean changes in languages which break compatibility with previous code. AFAIK, successful languages always had some periods (usually 2-3 years, sometimes more) when there were no additions to language and new major version didn't break existing code (for example: Java, C#, Ruby, Python, even C++ sometimes).

-- 
Regards,
Yauheni Akhotnikau

eao197 wrote:
> On Wed, 29 Aug 2007 23:15:26 +0400, Walter Bright <newshound1@digitalmars.com> wrote:
> 
>> eao197 wrote:
>>> Unfortunately I see to D's evolution, perhabs, from 2002 or 2003 year. It looks as D have never been a stable language.
>>
>>
>> I don't know any language in wide use that is stable (i.e. not changing). A stable language is a dead language.
> 
> I mean changes in languages which break compatibility with previous code. AFAIK, successful languages always had some periods (usually 2-3 years, sometimes more) when there were no additions to language and new major version didn't break existing code (for example: Java, C#, Ruby, Python, even C++ sometimes).

C++ has been around for 20+ years now. I'll grant that for maybe 2 of those years (10%) it was stable. C++ has the rather dubious distinction of it being very hard to get two different compilers to compile non-trivial code without some sort of code customization needed. As evidence of that, just browse the STL and Boost sources. While the C++ standard has been stable for a couple years (C++98, C++03), it being nearly impossible to implement has meant the implementations have been unstable.

For example, name lookup rules vary significantly *today* even among the major compilers. I regularly get bug reports that DMC++ does it wrong, even though it actually does it according to the Standard, and it's other compilers that get it wrong.

On the other hand, when C++ has been stable, it rapidly lost ground relative to other languages. The recent about face in rationale and flurry of core language additions to C++0x is evidence of that.

I haven't programmed long term in the other languages, so don't have a good basis for commenting on their stability.

I have been programming in C++ since 1987. It's pretty normal to take a C++ project from the past and have to dink around with it to get it to compile with a modern compiler. The odds of taking a few thousand lines of C++ pulled off the web that's set up to compile with C++ Brand X are about 0% for getting it to compile with C++ Brand Y without changes.

eao197 wrote:
> I mean changes in languages which break compatibility with previous code. AFAIK, successful languages always had some periods (usually 2-3 years, sometimes more) when there were no additions to language and new major version didn't break existing code (for example: Java, C#, Ruby, Python, even C++ sometimes).

I rather think, that a "new major version" of any language that "doesn't
break existing code" could hardly justify it's new major version number.
A complete rewrite of the compiler, e.g., would justify a majer new
compiler version, but not even a teeny-minor new language version.

An D /does have/ a stable language version, D1.

Regards, Frank

Walter Bright, el 30 de agosto a las 00:07 me escribiste:
> >>dead language.
> >I mean changes in languages which break compatibility with previous code. AFAIK, successful languages always had some periods (usually 2-3 years, sometimes more) when there were no additions to language and new major version didn't break existing code (for example: Java, C#, Ruby, Python, even C++ sometimes).
> 
> C++ has been around for 20+ years now. I'll grant that for maybe 2 of those years (10%) it was stable. C++ has the rather dubious distinction of it being very hard to get two different compilers to compile non-trivial code without some sort of code customization needed. As evidence of that, just browse the STL and Boost sources. While the C++ standard has been stable for a couple years (C++98, C++03), it being nearly impossible to implement has meant the implementations have been unstable.
> 
> For example, name lookup rules vary significantly *today* even among the major compilers. I regularly get bug reports that DMC++ does it wrong, even though it actually does it according to the Standard, and it's other compilers that get it wrong.
> 
> On the other hand, when C++ has been stable, it rapidly lost ground relative to other languages. The recent about face in rationale and flurry of core language additions to C++0x is evidence of that.
> 
> I haven't programmed long term in the other languages, so don't have a good basis for commenting on their stability.

Forget about C++ for a second. Try with Python. It is an stable, or at least *predictable* language. It's evolution is well structured, so you know you will have no suprises, and you know the language will evolve.

Python is *really* community driven (besides the BDFL[1] ;). It has a formal proposal system to make changes to the language: PEPs[2]. When a PEP is aproved, it's included in the next version and can be used *optionally* (if it could break backward compatibility). For example, you can use now the "future" behavoir of division:
>>> 10/3
3
>>> from __future__ import division
>>> 10/3
3.3333333333333335

In the next python version, the new feature is included without need to import __future__, and the old behavior is deprecated (for example, with libraries, when something changes, in the first version you can ask for the new feature, in the second the new feature is the default but you can fallback to the old behavior, and in the third version teh old behavior is completely removed).

[1] http://en.wikipedia.org/wiki/BDFL
[2] http://www.python.org/dev/peps/

> I have been programming in C++ since 1987. It's pretty normal to take a C++ project from the past and have to dink around with it to get it to compile with a modern compiler. The odds of taking a few thousand lines of C++ pulled off the web that's set up to compile with C++ Brand X are about 0% for getting it to compile with C++ Brand Y without changes.

You are talking about 20 years. D evolves in a daily basis and the worst is that this evolution is without any formal procedure. Forking D 2.0 was a huge improvement in this matter, but I think there's is more work to be done so D can success as a long term language (or at least to be trusted).

Another good step forward this could be to maintain phobos (or whatever the standard library would be :P) as an open source project. You can create a repository (please use git! :) so people can track its development and send patches easier. Same for the D frontend. It's almost impossible for someone who is used to colaborate in open source projects to do it with D. And that's a shame...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
 .------------------------------------------------------------------------,
  \  GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05 /
   '--------------------------------------------------------------------'
Pa' ella cociné, pa' ella lavé, pa' ella soñe
Paella completa, $2,50
Pero, la luz mala me tira, y yo? yo soy ligero pa'l trote
La luz buena, está en el monte, allá voy, al horizonte

On Thu, 30 Aug 2007 15:44:25 +0400, 0ffh <spam@frankhirsch.net> wrote:

> eao197 wrote:
>> I mean changes in languages which break compatibility with previous code. AFAIK, successful languages always had some periods (usually 2-3 years, sometimes more) when there were no additions to language and new major version didn't break existing code (for example: Java, C#, Ruby, Python, even C++ sometimes).
>
> I rather think, that a "new major version" of any language that "doesn't
> break existing code" could hardly justify it's new major version number.
> A complete rewrite of the compiler, e.g., would justify a majer new
> compiler version, but not even a teeny-minor new language version.

Java 1.5 (with generics) and C# 2.0 ware major versions, but didn't break old code.

>
> An D /does have/ a stable language version, D1.

http://d.puremagic.com/issues/show_bug.cgi?id=302  -- very strange bag for _stable_ version.

Try to imagine _stable_ Eiffel with broken DesignByContract support :-/

-- 
Regards,
Yauheni Akhotnikau