www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Help!

reply Manu <turkeyman gmail.com> writes:
template isThing( alias symbol, A )
{
  enum isThing = false;
}

This template works in most contexts:

int x;
struct S {}

pragma(msg, isThing!x);
pragma(msg, isThing!S);

But this fails:
pragma(msg, isThing!int);

Why does it fail on a basic type (int), but not a user defined type (S)?
How can I fix the template declaration to not error in that case?
I tried:

template isThing( alias symbol, A )
{
  enum isThing = false;
}
template isThing( T, A )
{
  enum isThing = false;
}

Hoping the T version would catch the int, but this leads to different
errors "matches more than one template declaration".
Nov 26 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 26 November 2012 at 16:37:08 UTC, Manu wrote:

 Why does it fail on a basic type (int), but not a user defined 
 type (S)?


S is a D symbol name, int isn't...


 How can I fix the template declaration to not error in that 
 case?


Try using only the (T,A) version, removing the alias version.

You might have to pass typeof(var) to it in some cases, but if 
you pass it typenames it should just work.
Nov 26 2012
parent Manu <turkeyman gmail.com> writes:
On 26 November 2012 18:40, Adam D. Ruppe <destructionator gmail.com> wrote:


 On Monday, 26 November 2012 at 16:37:08 UTC, Manu wrote:


 Why does it fail on a basic type (int), but not a user defined type (S)?


 S is a D symbol name, int isn't...


  How can I fix the template declaration to not error in that case?


 Try using only the (T,A) version, removing the alias version.

 You might have to pass typeof(var) to it in some cases, but if you pass it
 typenames it should just work.


The template works on symbol aliases, so I can't do that. It needs to
gracefully handle being given an int though somehow.



 Nov 26 2012



prev sibling next sibling parent reply "jerro" <a a.com>  writes:


 How can I fix the template declaration to not error in that 
 case?


If you want to have a template parameter that can be anything, 
including a a symbol or a built in type, you can use this ugly 
workaround:

template foo(bar...) if(bar.length == 1)
{
     enum foo = 1;
}



 Nov 26 2012



 next sibling parent reply Manu <turkeyman gmail.com>  writes:


On 26 November 2012 18:49, jerro <a a.com> wrote:


 How can I fix the template declaration to not error in that case?


 If you want to have a template parameter that can be anything, including a
 a symbol or a built in type, you can use this ugly workaround:

 template foo(bar...) if(bar.length == 1)
 {
     enum foo = 1;
 }


Ahhhhh, that explains why 90% of std.traits is written in that super-weird
way! I always wondered what that was all about.

When you say 'anything' though, does that include alias parameters? Will
bar[0] be the equivalent of template foo(alias bar) if called with a symbol?



 Nov 26 2012



  parent  "Jakob Ovrum" <jakobovrum gmail.com>  writes:


On Monday, 26 November 2012 at 17:06:14 UTC, Manu wrote:

 When you say 'anything' though, does that include alias 
 parameters? Will
 bar[0] be the equivalent of template foo(alias bar) if called 
 with a symbol?


Yes.

D's inbuilt tuples can have both "expressions" and types. Tuples 
with only the former are called expression tuples. Tuples with 
only the latter are called type tuples (which is why people 
complain about the name of std.typecons.TypeTuple - it doesn't 
just take types).



 Nov 26 2012



prev sibling  parent reply Manu <turkeyman gmail.com>  writes:


On 26 November 2012 19:06, Manu <turkeyman gmail.com> wrote:


 On 26 November 2012 18:49, jerro <a a.com> wrote:


  How can I fix the template declaration to not error in that case?


 If you want to have a template parameter that can be anything, including
 a a symbol or a built in type, you can use this ugly workaround:

 template foo(bar...) if(bar.length == 1)
 {
     enum foo = 1;
 }


 Ahhhhh, that explains why 90% of std.traits is written in that super-weird
 way! I always wondered what that was all about.

 When you say 'anything' though, does that include alias parameters? Will
 bar[0] be the equivalent of template foo(alias bar) if called with a symbol?


Ummm, immediate problem. That interferes with my argument list, inhibits
consecutive parameters. You'll notice my template had 'A' on the end... it
would make for a horrible API if the second arg were to come first in this
case... is that the only option?



 Nov 26 2012



 next sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com>  writes:


26.11.2012 21:11, Manu пишет:

 Ummm, immediate problem. That interferes with my argument list, inhibits
 consecutive parameters. You'll notice my template had 'A' on the end...
 it would make for a horrible API if the second arg were to come first in
 this case... is that the only option?


Yes it is the only option. And it isn't really a big problem.


-- 
Денис В. Шеломовский
Denis V. Shelomovskij



 Nov 26 2012



  parent reply Manu <turkeyman gmail.com>  writes:


On 26 November 2012 19:14, Denis Shelomovskij
<verylonglogin.reg gmail.com>wrote:


 26.11.2012 21:11, Manu =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

  Ummm, immediate problem. That interferes with my argument list, inhibits

 consecutive parameters. You'll notice my template had 'A' on the end...
 it would make for a horrible API if the second arg were to come first in
 this case... is that the only option?


 Yes it is the only option. And it isn't really a big problem.



It's a public user-facing API. It's not a small problem, but it is
workable...
However, going with that, the supplementary question is, how do I then
discover if bar[0] is a symbol or not? I can't see any traits to test for
builtin types...



 Nov 26 2012



 next sibling parent reply "jerro" <a a.com>  writes:


 However, going with that, the supplementary question is, how do 
 I then
 discover if bar[0] is a symbol or not? I can't see any traits 
 to test for
 builtin types...


You could use the fact that alias parameters can not be builtin 
types, like this:

template TestSymbol(alias a){}

  __traits(compiles, TestSymbol!(bar[0]))



 Nov 26 2012



  parent  Manu <turkeyman gmail.com>  writes:


On 26 November 2012 19:28, jerro <a a.com> wrote:


 However, going with that, the supplementary question is, how do I then

 discover if bar[0] is a symbol or not? I can't see any traits to test for
 builtin types...


 You could use the fact that alias parameters can not be builtin types,
 like this:

 template TestSymbol(alias a){}

  __traits(compiles, TestSymbol!(bar[0]))



_< .. I feel like crying every time 'compiles' comes up.





 Nov 26 2012



prev sibling  parent reply "David Nadlinger" <see klickverbot.at>  writes:


On Monday, 26 November 2012 at 17:18:28 UTC, Manu wrote:

 the supplementary question is, how do I then
 discover if bar[0] is a symbol or not? I can't see any traits 
 to test for
 builtin types...


Depends on your definition of symbol, but if you mean symbol as 
in "an alias parameter accepts it", the obvious solution is:

---
template isSymbol(alias S) {
   enum isSymbol = true;
}

template isSymbol(S) {
   enum isSymbol = false;
}
---

David



 Nov 26 2012



  parent reply Manu <turkeyman gmail.com>  writes:


On 26 November 2012 21:15, David Nadlinger <see klickverbot.at> wrote:


 On Monday, 26 November 2012 at 17:18:28 UTC, Manu wrote:


 the supplementary question is, how do I then
 discover if bar[0] is a symbol or not? I can't see any traits to test for
 builtin types...


 Depends on your definition of symbol, but if you mean symbol as in "an
 alias parameter accepts it", the obvious solution is:

 ---
 template isSymbol(alias S) {
   enum isSymbol = true;
 }

 template isSymbol(S) {
   enum isSymbol = false;
 }
 ---

 David


struct S {}
isSymbol!S <- why isn't this ambiguous? both templates match that equally,
why would it prefer the alias one?



 Nov 26 2012



 next sibling parent  "David Nadlinger" <see klickverbot.at>  writes:


On Monday, 26 November 2012 at 19:43:18 UTC, Manu wrote:

 struct S {}
 isSymbol!S <- why isn't this ambiguous? both templates match 
 that equally,
 why would it prefer the alias one?


I don't know OTOH if it's documented or not, but that's just how 
template resolution rules work. But anyway, Timon has just 
pointed out that Walter isn't opposed to the change anymore. It's 
now considered a bug:

http://d.puremagic.com/issues/show_bug.cgi?id=9029

David



 Nov 26 2012



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 11/27/2012 6:43 AM, Manu wrote:

 struct S {}
 isSymbol!S <- why isn't this ambiguous? both templates match that
 equally, why would it prefer the alias one?


When two templates match an argument list, the compiler picks the most 
specialized match.



 Nov 26 2012



  parent reply "David Nadlinger" <see klickverbot.at>  writes:


On Monday, 26 November 2012 at 19:54:46 UTC, Walter Bright wrote:

 On 11/27/2012 6:43 AM, Manu wrote:

 struct S {}
 isSymbol!S <- why isn't this ambiguous? both templates match 
 that
 equally, why would it prefer the alias one?


 When two templates match an argument list, the compiler picks 
 the most specialized match.


Yes, but this requires that "alias T" and "T" are (totally) 
ordered, which is not clear, a priori.

David



 Nov 26 2012



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 11/26/2012 08:58 PM, David Nadlinger wrote:

 On Monday, 26 November 2012 at 19:54:46 UTC, Walter Bright wrote:

 On 11/27/2012 6:43 AM, Manu wrote:

 struct S {}
 isSymbol!S <- why isn't this ambiguous? both templates match that
 equally, why would it prefer the alias one?


 When two templates match an argument list, the compiler picks the most
 specialized match.


 Yes, but this requires that "alias T" and "T" are (totally) ordered,
 which is not clear, a priori.

 David


Yes, not every alias argument is a valid type, so why would the alias be 
considered more specialized?



 Nov 26 2012



prev sibling  parent  "jerro" <a a.com>  writes:


 Ummm, immediate problem. That interferes with my argument list, 
 inhibits
 consecutive parameters. You'll notice my template had 'A' on 
 the end... it
 would make for a horrible API if the second arg were to come 
 first in this
 case... is that the only option?


You could just take all parameters as a tuple, and them constrain 
them usin "if", like that:

template bar(foo...) if(foo.length == 2 && is(foo[1]))
{
}



 Nov 26 2012



prev sibling next sibling parent  Denis Shelomovskij <verylonglogin.reg gmail.com>  writes:


26.11.2012 20:36, Manu пишет:

 template isThing( alias symbol, A )
 {
    enum isThing = false;
 }

 This template works in most contexts:

 int x;
 struct S {}

 pragma(msg, isThing!x);
 pragma(msg, isThing!S);

 But this fails:
 pragma(msg, isThing!int);

 Why does it fail on a basic type (int), but not a user defined type (S)?
 How can I fix the template declaration to not error in that case?
 I tried:

 template isThing( alias symbol, A )
 {
    enum isThing = false;
 }
 template isThing( T, A )
 {
    enum isThing = false;
 }

 Hoping the T version would catch the int, but this leads to different
 errors "matches more than one template declaration".


First, your `isThing` requires 2 parameters so all examples will fail to 
compile. Probably you meant `isThing(alias symbol)`.

Second, build-in type isn't a valid template alias parameter (probably 
as it isn't a "symbol"), see docs:
http://dlang.org/template.html#TemplateAliasParameter

Third, a workaround is to use template tuple parameter (as already 
suggested in this thread).

-- 
Денис В. Шеломовский
Denis V. Shelomovskij



 Nov 26 2012



prev sibling  parent reply "Max Samukha" <maxsamukha gmail.com>  writes:


On Monday, 26 November 2012 at 16:37:08 UTC, Manu wrote:

 template isThing( alias symbol, A )
 {
   enum isThing = false;
 }

 This template works in most contexts:

 int x;
 struct S {}

 pragma(msg, isThing!x);
 pragma(msg, isThing!S);

 But this fails:
 pragma(msg, isThing!int);

 Why does it fail on a basic type (int), but not a user defined 
 type (S)?
 How can I fix the template declaration to not error in that 
 case?
 I tried:

 template isThing( alias symbol, A )
 {
   enum isThing = false;
 }
 template isThing( T, A )
 {
   enum isThing = false;
 }

 Hoping the T version would catch the int, but this leads to 
 different
 errors "matches more than one template declaration".


That is annoying. There *must* be a kind of single unconstrained 
template parameter accepting anything that can be an element of a 
"compile time" tuple. In other words, this must work for any 
arguments without hassle:

template Foo(alias Head, Tail...)
{
     alias TypeTuple!(Head, Tail) Foo;
}

As others said, you can workaround the deficiency with an 
if-constraint, which is unsightly. FWIW, I have all my codebase 
littered with "if (A.length == 1)" rubbish.



 Nov 26 2012



  parent reply "David Nadlinger" <see klickverbot.at>  writes:


On Monday, 26 November 2012 at 18:20:39 UTC, Max Samukha wrote:

 That is annoying. There *must* be a kind of single 
 unconstrained template parameter accepting anything that can be 
 an element of a "compile time" tuple. In other words, this must 
 work for any arguments without hassle:

 template Foo(alias Head, Tail...)
 {
     alias TypeTuple!(Head, Tail) Foo;
 }

 As others said, you can workaround the deficiency with an 
 if-constraint, which is unsightly. FWIW, I have all my codebase 
 littered with "if (A.length == 1)" rubbish.


I agree, and if I remember previous discussions on the subject 
correctly, it seems like only Walter is in favor of upholding the 
current restrictions of "alias" parameters to symbols. I simply 
do not see a point in pushing compiler implementation details on 
the user like that – for the programmer, a type is a type is a 
type…

Walter, do you have an example of a situation where the alias 
parameter restriction would be beneficial?  (for the D code 
involved, I don't mean the few lines of code avoided in the 
compiler)

David



 Nov 26 2012



 next sibling parent reply "Eldar Insafutdinov" <e.insafutdinov gmail.com>  writes:


On Monday, 26 November 2012 at 18:52:25 UTC, David Nadlinger 
wrote:

 I agree, and if I remember previous discussions on the subject 
 correctly, it seems like only Walter is in favor of upholding 
 the current restrictions of "alias" parameters to symbols.

 David


The problem lies within how the compiler is engineered. Basic 
built-in types should be a part of symbol table and inserted into 
it at the compiler startup. That means that any mentioning of 
built-in types in the parser should be removed and any 
differences between user defined symbols and basic types should 
be as small as possible. That will remove many special cases from 
the compiler as well as automatically resolve the alias problem. 
As far as I understand this is how basic types are implemented in 
the Haskell compiler.

Cheers

Eldar



 Nov 26 2012



 next sibling parent  "David Nadlinger" <see klickverbot.at>  writes:


On Monday, 26 November 2012 at 19:17:30 UTC, Eldar Insafutdinov 
wrote:

 On Monday, 26 November 2012 at 18:52:25 UTC, David Nadlinger 
 wrote:

 I agree, and if I remember previous discussions on the subject 
 correctly, it seems like only Walter is in favor of upholding 
 the current restrictions of "alias" parameters to symbols.

 David


 The problem lies within how the compiler is engineered. […]


I'm aware of this – that's why I wrote »I don't mean the few 
lines of code avoided in the
compiler« in the piece of my post you silently dropped from your 
quote. ;)

David



 Nov 26 2012



prev sibling  parent  "Eldar Insafutdinov" <e.insafutdinov gmail.com>  writes:


On Monday, 26 November 2012 at 19:17:30 UTC, Eldar Insafutdinov 
wrote:

 The problem lies within how the compiler is engineered. Basic 
 built-in types should be a part of symbol table and inserted 
 into it at the compiler startup. That means that any mentioning 
 of built-in types in the parser should be removed and any 
 differences between user defined symbols and basic types should 
 be as small as possible. That will remove many special cases 
 from the compiler as well as automatically resolve the alias 
 problem. As far as I understand this is how basic types are 
 implemented in the Haskell compiler.

 Cheers

 Eldar


Although I realize now that this will not make alias accept 
derived types like arrays, pointers etc. But regardless, 
distinction between built-in and user defined types should be 
very little, even in the compiler internals. In the end this is 
the whole point of OOP which allows for the user to make the 
types which are just as good as internal ones.



 Nov 26 2012



prev sibling next sibling parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 11/26/2012 07:52 PM, David Nadlinger wrote:

 On Monday, 26 November 2012 at 18:20:39 UTC, Max Samukha wrote:

 That is annoying. There *must* be a kind of single unconstrained
 template parameter accepting anything that can be an element of a
 "compile time" tuple. In other words, this must work for any arguments
 without hassle:

 template Foo(alias Head, Tail...)
 {
     alias TypeTuple!(Head, Tail) Foo;
 }

 As others said, you can workaround the deficiency with an
 if-constraint, which is unsightly. FWIW, I have all my codebase
 littered with "if (A.length == 1)" rubbish.


 I agree, and if I remember previous discussions on the subject
 correctly, it seems like only Walter is in favor of upholding the
 current restrictions of "alias" parameters to symbols. I simply do not
 see a point in pushing compiler implementation details on the user like
 that – for the programmer, a type is a type is a type…

 Walter, do you have an example of a situation where the alias parameter
 restriction would be beneficial?  (for the D code involved, I don't mean
 the few lines of code avoided in the compiler)

 David


There are none. In case that behaviour is wanted, a template constraint 
does the job.

http://forum.dlang.org/thread/k7uc5p$2giu$1 digitalmars.com?page=3#post-k815mi:2410hh:242:40digitalmars.com

http://d.puremagic.com/issues/show_bug.cgi?id=9029



 Nov 26 2012



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 11/27/2012 5:52 AM, David Nadlinger wrote:

 I agree, and if I remember previous discussions on the subject
 correctly, it seems like only Walter is in favor of upholding the
 current restrictions of "alias" parameters to symbols. I simply do not
 see a point in pushing compiler implementation details on the user like
 that – for the programmer, a type is a type is a type…

 Walter, do you have an example of a situation where the alias parameter
 restriction would be beneficial?  (for the D code involved, I don't mean
 the few lines of code avoided in the compiler)


In any case, it will break a great deal of existing code to change  that 
behavior.



 Nov 26 2012



 next sibling parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 11/26/2012 08:59 PM, Walter Bright wrote:

 On 11/27/2012 5:52 AM, David Nadlinger wrote:

 I agree, and if I remember previous discussions on the subject
 correctly, it seems like only Walter is in favor of upholding the
 current restrictions of "alias" parameters to symbols. I simply do not
 see a point in pushing compiler implementation details on the user like
 that – for the programmer, a type is a type is a type…

 Walter, do you have an example of a situation where the alias parameter
 restriction would be beneficial?  (for the D code involved, I don't mean
 the few lines of code avoided in the compiler)


 In any case, it will break a great deal of existing code to change  that
 behavior.


Well, no, it wont. Why do you think it will?



 Nov 26 2012



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 11/27/2012 7:09 AM, Timon Gehr wrote:

 In any case, it will break a great deal of existing code to change  that
 behavior.


 Well, no, it wont. Why do you think it will?


Because (as this thread shows) a lot of template code has been built 
around subtle things like this.



 Nov 26 2012



prev sibling next sibling parent reply "Eldar Insafutdinov" <e.insafutdinov gmail.com>  writes:


On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:

 On 11/27/2012 5:52 AM, David Nadlinger wrote:

 I agree, and if I remember previous discussions on the subject
 correctly, it seems like only Walter is in favor of upholding 
 the
 current restrictions of "alias" parameters to symbols. I 
 simply do not
 see a point in pushing compiler implementation details on the 
 user like
 that – for the programmer, a type is a type is a type…

 Walter, do you have an example of a situation where the alias 
 parameter
 restriction would be beneficial?  (for the D code involved, I 
 don't mean
 the few lines of code avoided in the compiler)


 In any case, it will break a great deal of existing code to 
 change  that behavior.


The discussed issue is one of those inconsistencies that make 
people struggle when using D. D's main selling point is rich 
metaprogramming. Others are rapidly catching up in the field of 
expressive native languages. If we set these early design 
decisions in stone, it means we will not be able to compete with 
them. And besides, are there many big proprietary D2 codebases 
that you afraid? I doubt there are. And Manu actually represents 
people who are willing to work on one, but are held off by these 
issues. Open source projects however will be easily fixable, and 
people using D will actually welcome these positive changes.



 Nov 27 2012



 next sibling parent reply Manu <turkeyman gmail.com>  writes:


On 27 November 2012 19:47, Eldar Insafutdinov <e.insafutdinov gmail.com>wro=
te:


 On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:


 On 11/27/2012 5:52 AM, David Nadlinger wrote:


 I agree, and if I remember previous discussions on the subject
 correctly, it seems like only Walter is in favor of upholding the
 current restrictions of "alias" parameters to symbols. I simply do not
 see a point in pushing compiler implementation details on the user like
 that =E2=80=93 for the programmer, a type is a type is a type=E2=80=A6

 Walter, do you have an example of a situation where the alias parameter
 restriction would be beneficial?  (for the D code involved, I don't mea=






n

 the few lines of code avoided in the compiler)


 In any case, it will break a great deal of existing code to change  that
 behavior.


 The discussed issue is one of those inconsistencies that make people
 struggle when using D. D's main selling point is rich metaprogramming.
 Others are rapidly catching up in the field of expressive native language=


s.

 If we set these early design decisions in stone, it means we will not be
 able to compete with them. And besides, are there many big proprietary D2
 codebases that you afraid? I doubt there are. And Manu actually represent=


s

 people who are willing to work on one, but are held off by these issues.
 Open source projects however will be easily fixable, and people using D
 will actually welcome these positive changes.


I feel this sentiment every day.
I'm more than happy to receive breaking changes that make the language
tidier and more consistent. I'll happily take the time to keep our codebase
up to date.
As a commercial entity, I'd rather see the language assert breaking changes
that make the language feel more solid/robust than to continue implementing
ugly hacks/workarounds for sake of not breaking our codebase.
Surely it's better to sweep the foundations while users range in the 4-5
digits, than the 6-7 digits (which is surely the hope here)?

There is a lot of nasty clutter/mess in the lowest level of D (and the
useful parts should generally be wrapped up in std.traits anyway) ;)
Just look through std.traits at some of the wild approaches required to
discover certain properties about things. Our code is equally riddled with
stuff like that, though it's gotten a lot better in the past 2 months!



 Nov 27 2012



  parent  "Rob T" <rob ucora.com>  writes:


On Tuesday, 27 November 2012 at 18:10:51 UTC, Manu wrote:

 I feel this sentiment every day.
 I'm more than happy to receive breaking changes that make the 
 language
 tidier and more consistent. I'll happily take the time to keep 
 our codebase
 up to date.


I agree more than 100%. I've been struggling with inconsistency 
issues right from the get go, and it's very frustrating, esp when 
you see the brilliant potential that should be there but just 
quite isn't.

A suggested improvement written up here, solves at least some of 
it
http://forum.dlang.org/thread/xxenmxyshhscjhqjibkr forum.dlang.org

--rt



 Nov 27 2012



prev sibling  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org>  writes:


Am 27.11.2012 18:47, schrieb Eldar Insafutdinov:

 On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:

 On 11/27/2012 5:52 AM, David Nadlinger wrote:

 I agree, and if I remember previous discussions on the subject
 correctly, it seems like only Walter is in favor of upholding the
 current restrictions of "alias" parameters to symbols. I simply do not
 see a point in pushing compiler implementation details on the user like
 that – for the programmer, a type is a type is a type…

 Walter, do you have an example of a situation where the alias parameter
 restriction would be beneficial?  (for the D code involved, I don't mean
 the few lines of code avoided in the compiler)


 In any case, it will break a great deal of existing code to change  that
behavior.


 
 The discussed issue is one of those inconsistencies that make people struggle
when using D. D's main
 selling point is rich meta programming. Others are rapidly catching up in the
field of expressive
 native languages. If we set these early design decisions in stone, it means we
will not be able to
 compete with them. And besides, are there many big proprietary D2 codebases
that you afraid? I doubt
 there are. And Manu actually represents people who are willing to work on one,
but are held off by
 these issues. Open source projects however will be easily fixable, and people
using D will actually
 welcome these positive changes.


We do have a largish code base that is also gradually used commercially (200k+
lines of library
code, when including vibe.d plus any applications that are built on top of it).
My former employee
now has a smaller code base along the lines of 80k+ LOC). So I guess such code
bases are in fact a
reality.

... and still I very much prefer to have "good" breakage that cleans up the
language. It's just
things that break code for nothing (most of the time bugs) that are really
annoying.

And I fully agree, we should better collect warts of the language and fix them
as early as possible.
This may set up a few people now, but will make all the future users of the
language + a lot of the
current users much more happy.

Realistically, the current approach with one branch that is not supposed to get
breaking changes,
but gets them anyway as soon as it _has to_, just extends the period of time in
which things get
broken and also in which the language still has those issues.



 Nov 27 2012



  parent  "Rob T" <rob ucora.com>  writes:


I'm also attempting to utilize D on a commercial basis in an 
attempt to gain productivity benefits over C++. I'm willing to 
put up with some bugs and a few breaking changes so long as I see 
D is improving for the better, and at a decent pace.

I think what this forum definitely could use is a place holder 
for commercial users. That way the D developers can see what is 
working well and what is not when the language is put to real 
use. Everyone will win from having that.

--rt



 Nov 27 2012



prev sibling next sibling parent reply "Max Samukha" <maxsamukha gmail.com>  writes:


On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:

 On 11/27/2012 5:52 AM, David Nadlinger wrote:

 I agree, and if I remember previous discussions on the subject
 correctly, it seems like only Walter is in favor of upholding 
 the
 current restrictions of "alias" parameters to symbols. I 
 simply do not
 see a point in pushing compiler implementation details on the 
 user like
 that – for the programmer, a type is a type is a type…

 Walter, do you have an example of a situation where the alias 
 parameter
 restriction would be beneficial?  (for the D code involved, I 
 don't mean
 the few lines of code avoided in the compiler)


 In any case, it will break a great deal of existing code to 
 change  that behavior.


Please stop repeating that "will break lots of code" mantra. D 
user base is very small and it doesn't grow *because* issues like 
the one discussed do not get fixed. When they are fixed people 
may start using the language. And *then* you would have to worry 
about backward compatibility. Look at the recent Manu's 
complaints and see what people who would really use the language 
have wanted from it for years.



 Nov 27 2012



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 11/28/2012 5:25 AM, Max Samukha wrote:

 Please stop repeating that "will break lots of code" mantra. D user base
 is very small and it doesn't grow *because* issues like the one
 discussed do not get fixed. When they are fixed people may start using
 the language. And *then* you would have to worry about backward
 compatibility. Look at the recent Manu's complaints and see what people
 who would really use the language have wanted from it for years.


I understand what you're saying, but the counterpoint is we lost half 
the D community when D2 broke D1 code. We still have at least one major 
D1 user that still finds it impractical to upgrade to D2.

It is unbelievably frustrating for people to have their code break with 
each new release, have older projects all invalidated, with few willing 
to do the maintenance work to bring them back on line.



 Nov 27 2012



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 11/28/2012 8:23 AM, Walter Bright wrote:

 It is unbelievably frustrating for people to have their code break with
 each new release, have older projects all invalidated, with few willing
 to do the maintenance work to bring them back on line.



Note the thread next to this one: "Errors compiling DSSS", and the 
advice to abandon it.



 Nov 27 2012



  parent  "Max Samukha" <maxsamukha gmail.com>  writes:


On Tuesday, 27 November 2012 at 21:26:47 UTC, Walter Bright wrote:

 On 11/28/2012 8:23 AM, Walter Bright wrote:

 It is unbelievably frustrating for people to have their code 
 break with
 each new release, have older projects all invalidated, with 
 few willing
 to do the maintenance work to bring them back on line.



 Note the thread next to this one: "Errors compiling DSSS", and 
 the advice to abandon it.


It looks I am living in a parallel reality. In my world, DSSS has 
been abandoned for 4(!) years already! The author quit long 
before D2 feature-freeze was announced. There are a couple of 
forks but they do not seem to be maintained either. Why would 
anyone expect an unmaintained project like that to compile with 
new versions of an evolving language?

Most open source projects die. Students get jobs. That happens. 
Even the "stable" dmd1 is unlikely to compile any abandoned 
project at dsource. dsource itself is down more often than not. 
Should we keep them on life support?



 Nov 28 2012



prev sibling next sibling parent  "Rob T" <rob ucora.com>  writes:


On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:

 I understand what you're saying, but the counterpoint is we 
 lost half the D community when D2 broke D1 code. We still have 
 at least one major D1 user that still finds it impractical to 
 upgrade to D2.

 It is unbelievably frustrating for people to have their code 
 break with each new release, have older projects all 
 invalidated, with few willing to do the maintenance work to 
 bring them back on line.


It may not be my place to say, but the unwillingness to maintain 
the D1 code seems to go well past just breakage issues.

Anyway, I figure D at this time is attracting mostly "early 
adopters" who don't always mind the odd breakage here and there 
so long as it's for the greater good. Once the D base expands 
beyond the early adopter phase, change will become much more 
difficult than it is right now, so whatever is being done today 
better be done well before it's too late.

My only suggestion is to re-think how a programming language can 
remain reasonably stable, yet at the same time evolve forward in 
significant ways over the long term. There must be plenty of 
real-world examples of this being done successfully that can be 
emulated with D.

If D is not allowed to change in significant ways, then it will 
slowly but surely become another C/C++, with "significant" 
updates once every 10 years or so which are mediocre and leave 
the root design defects in place.

--rt



 Nov 27 2012



prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Walter Bright:


 It is unbelievably frustrating for people to have their code 
 break with each new release, have older projects all 
 invalidated, with few willing to do the maintenance work to 
 bring them back on line.


I am still converting some of my D1 code to D2, plus I have lot 
of D2 code. Since many months I have stopped downloading official 
dmd releases because the amount of breakages in my D2 code 
between a version and the successive one was too much large. DMD 
2.061 has so many changes and improvements that it will require 
several changes in everyone D2 code.

To avoid performing such large amount of changes I now compile 
dmd every two or three days, and I have scripts that compile all 
my D2 programs and report the breakages. This way I fix a small 
amount of breakages at a time in my D2 code, this is simpler.

Most of those breakages are caused by bug fixings that reveal 
bugs in my D2 code (example: since recently throwing constructors 
accepted a nothrow tag, and I have many more examples). But I am 
willing to perform this maintenance work because they improve my 
future D2 programming and code.

If we add to those bug-fixing-changes some breakage caused by 
design changes, this is not going to make my live significantly 
worse, it's just one more breakage among several others.

Bye,
bearophile



 Nov 27 2012



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 28 November 2012 at 00:07:42 UTC, bearophile wrote:

 Walter Bright:


 It is unbelievably frustrating for people to have their code 
 break with each new release, have older projects all 
 invalidated, with few willing to do the maintenance work to 
 bring them back on line.


 I am still converting some of my D1 code to D2, plus I have lot 
 of D2 code. Since many months I have stopped downloading 
 official dmd releases because the amount of breakages in my D2 
 code between a version and the successive one was too much 
 large. DMD 2.061 has so many changes and improvements that it 
 will require several changes in everyone D2 code.

 To avoid performing such large amount of changes I now compile 
 dmd every two or three days, and I have scripts that compile 
 all my D2 programs and report the breakages. This way I fix a 
 small amount of breakages at a time in my D2 code, this is 
 simpler.

 Most of those breakages are caused by bug fixings that reveal 
 bugs in my D2 code (example: since recently throwing 
 constructors accepted a nothrow tag, and I have many more 
 examples). But I am willing to perform this maintenance work 
 because they improve my future D2 programming and code.

 If we add to those bug-fixing-changes some breakage caused by 
 design changes, this is not going to make my live significantly 
 worse, it's just one more breakage among several others.


Don't you think that this whole situation is due to adding 
feature after feature in an unstabilized mess ?

I mean, how the fact that a nothrow constructor can throw can be 
explained in another way (to use your example) ? A feature in 
that state should have reached any release, ever !



 Nov 27 2012



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 02:40, deadalnix wrote:


 Don't you think that this whole situation is due to adding feature after
 feature in an unstabilized mess ?


It is, that's the major problem with D. Not the actual code breakage, 
rather how those are introduced.

-- 
/Jacob Carlborg



 Nov 27 2012



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/28/12 2:38 AM, Jacob Carlborg wrote:

 On 2012-11-28 02:40, deadalnix wrote:


 Don't you think that this whole situation is due to adding feature after
 feature in an unstabilized mess ?


 It is, that's the major problem with D. Not the actual code breakage,
 rather how those are introduced.


I agree. We must drop this mom-and-pop-shop attitude like a bad habit.

Andrei



 Nov 28 2012



prev sibling  parent  Manu <turkeyman gmail.com>  writes:


On 28 November 2012 03:40, deadalnix <deadalnix gmail.com> wrote:


 On Wednesday, 28 November 2012 at 00:07:42 UTC, bearophile wrote:


 Walter Bright:

  It is unbelievably frustrating for people to have their code break with

 each new release, have older projects all invalidated, with few willing to
 do the maintenance work to bring them back on line.


 I am still converting some of my D1 code to D2, plus I have lot of D2
 code. Since many months I have stopped downloading official dmd releases
 because the amount of breakages in my D2 code between a version and the
 successive one was too much large. DMD 2.061 has so many changes and
 improvements that it will require several changes in everyone D2 code.

 To avoid performing such large amount of changes I now compile dmd every
 two or three days, and I have scripts that compile all my D2 programs and
 report the breakages. This way I fix a small amount of breakages at a time
 in my D2 code, this is simpler.

 Most of those breakages are caused by bug fixings that reveal bugs in my
 D2 code (example: since recently throwing constructors accepted a nothrow
 tag, and I have many more examples). But I am willing to perform this
 maintenance work because they improve my future D2 programming and code.

 If we add to those bug-fixing-changes some breakage caused by design
 changes, this is not going to make my live significantly worse, it's just
 one more breakage among several others.


 Don't you think that this whole situation is due to adding feature after
 feature in an unstabilized mess ?


Not really. I haven't seen any problems in any new stuff since I've been
around.

Almost all the issues I encounter stem from the type system (like the
alias/builtin type thing discussed), tuples (value/expression/type tuples?
what is the syntax to identify these? what are they exactly?),
is()/__traits not identifying things cleanly (strange workarounds to
identify seemingly trivial details)... and ref.

Every one of these things was in the language before I started using it, so
at least to me, they feel like old features that have just always been
there...


I mean, how the fact that a nothrow constructor can throw can be explained

 in another way (to use your example) ? A feature in that state should have
 reached any release, ever !





 Nov 28 2012



prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:

 On 11/28/2012 5:25 AM, Max Samukha wrote:

 Please stop repeating that "will break lots of code" mantra. D 
 user base
 is very small and it doesn't grow *because* issues like the one
 discussed do not get fixed. When they are fixed people may 
 start using
 the language. And *then* you would have to worry about backward
 compatibility. Look at the recent Manu's complaints and see 
 what people
 who would really use the language have wanted from it for 
 years.


 I understand what you're saying, but the counterpoint is we 
 lost half the D community when D2 broke D1 code. We still have 
 at least one major D1 user that still finds it impractical to 
 upgrade to D2.


Should we talk about phobos and tango here ? I'm pretty sure you 
can attribute most of that departure from that event.


 It is unbelievably frustrating for people to have their code 
 break with each new release, have older projects all 
 invalidated, with few willing to do the maintenance work to 
 bring them back on line.


I have also bunch of code broken in the current release and find 
myself writing workaround for quirk in the language even for 
simple monomodule programs.

We have a project management issue here in the first place.



 Nov 27 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 01:56, deadalnix wrote:


 We have a project management issue here in the first place.


I completely agree.

-- 
/Jacob Carlborg



 Nov 27 2012



prev sibling next sibling parent reply "Mike Parker" <aldacron gmail.com>  writes:


On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:

 On 11/28/2012 5:25 AM, Max Samukha wrote:

 Please stop repeating that "will break lots of code" mantra. D 
 user base
 is very small and it doesn't grow *because* issues like the one
 discussed do not get fixed. When they are fixed people may 
 start using
 the language. And *then* you would have to worry about backward
 compatibility. Look at the recent Manu's complaints and see 
 what people
 who would really use the language have wanted from it for 
 years.


 I understand what you're saying, but the counterpoint is we 
 lost half the D community when D2 broke D1 code. We still have 
 at least one major D1 user that still finds it impractical to 
 upgrade to D2.


That was more than a breaking change. That was a massive paradigm 
shift. All the drama going on back then was rooted more in 
philosophical differences and the Phobos/Tango divide, than 
changes to the language. What's being discussed here is breakage 
on a much smaller scale.

I've always said that it's the little things in aggregate that 
make D such a wonderful language to work with. But the flipside 
of that is the little annoyances in aggregate can make it 
frustrating to work with. New users coming to a language often 
have little patience. IMO, their encountering these little 
annoyances before the good stuff takes hold is a far more 
pressing issue than a few minor breaking changes.

I've no idea what sort of commercial interests are using D in 
production, but I'd still confidently make the bet that a few 
breaking changes now (for issues that people find frustrating) 
would do more good than harm in the long run. Especially if they 
are introduced gradually and with time to understand their 
ramifications.



 Nov 27 2012



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 02:30, Mike Parker wrote:


 I've no idea what sort of commercial interests are using D in
 production, but I'd still confidently make the bet that a few breaking
 changes now (for issues that people find frustrating) would do more good
 than harm in the long run. Especially if they are introduced gradually
 and with time to understand their ramifications.


There's been a few post in this thread mentioning they work on a 
commercial code base using D. They all came to the same conclusion that 
the code breaking is worth it if it fixes actual problems in the language.

-- 
/Jacob Carlborg



 Nov 27 2012



prev sibling  parent  Manu <turkeyman gmail.com>  writes:


On 28 November 2012 03:30, Mike Parker <aldacron gmail.com> wrote:


 On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:


 On 11/28/2012 5:25 AM, Max Samukha wrote:


 Please stop repeating that "will break lots of code" mantra. D user base
 is very small and it doesn't grow *because* issues like the one
 discussed do not get fixed. When they are fixed people may start using
 the language. And *then* you would have to worry about backward
 compatibility. Look at the recent Manu's complaints and see what people
 who would really use the language have wanted from it for years.


 I understand what you're saying, but the counterpoint is we lost half the
 D community when D2 broke D1 code. We still have at least one major D1 user
 that still finds it impractical to upgrade to D2.


 That was more than a breaking change. That was a massive paradigm shift.
 All the drama going on back then was rooted more in philosophical
 differences and the Phobos/Tango divide, than changes to the language.
 What's being discussed here is breakage on a much smaller scale.

 I've always said that it's the little things in aggregate that make D such
 a wonderful language to work with. But the flipside of that is the little
 annoyances in aggregate can make it frustrating to work with. New users
 coming to a language often have little patience. IMO, their encountering
 these little annoyances before the good stuff takes hold is a far more
 pressing issue than a few minor breaking changes.


Very important point! I'm far more patient and persistent than others in my
company...

I've no idea what sort of commercial interests are using D in production,

 but I'd still confidently make the bet that a few breaking changes now (for
 issues that people find frustrating) would do more good than harm in the
 long run. Especially if they are introduced gradually and with time to
 understand their ramifications.





 Nov 28 2012



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-27 22:23, Walter Bright wrote:


 I understand what you're saying, but the counterpoint is we lost half
 the D community when D2 broke D1 code. We still have at least one major
 D1 user that still finds it impractical to upgrade to D2.


That was more an issue of how the community and project were run (or 
rather not run). Not the actual code breakage.


 It is unbelievably frustrating for people to have their code break with
 each new release, have older projects all invalidated, with few willing
 to do the maintenance work to bring them back on line.


I think it's just as unbelievably frustrating to freeze a language at a 
given point without thinking of the implications. Or declaring that a 
language cannot receive any more breaking changes when it's far from 
done and many things aren't working properly.

I cannot believe how you could consider D stable when your adding new 
features directly to the master branch willy nilly. A book was released 
way, way too soon for a language far from ready.

This is mostly a problem about how the project is run and managed. No 
road map, a poor release process, committing new features directly to 
the master branch. Unstable features added, added even before they're 
can be considered finished. I mean, "const" was one of the first things 
added to D2, it still has problems and druntime/Phobos is still not 
const correct.

We have complained before, quite often Andrei agrees that several things 
need to be changed but it's not much that happens.

-- 
/Jacob Carlborg



 Nov 27 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/28/12 2:55 AM, Jacob Carlborg wrote:

 This is mostly a problem about how the project is run and managed. No
 road map, a poor release process, committing new features directly to
 the master branch. Unstable features added, added even before they're
 can be considered finished. I mean, "const" was one of the first things
 added to D2, it still has problems and druntime/Phobos is still not
 const correct.


Totally agreed. One issue now is that Walter has converged briskly on 
the simplistic conclusion "no more steenking breakages" instead of 
learning git and designing a useful process around it. That way the 
process remains broken instead of being identified as the main issue and 
fixed. I have advocated privately in much stronger terms than I could 
afford publicly that we must fix the process and exercise good judgment 
about changing the language - all to no avail. "No more breakages" is 
like taking an aspirin for the fever caused by gangrene.

I think with dread about what's coming when completing shared will be on 
the table. We'll be looking at not breaking code that was by definition 
broken.


Andrei



 Nov 28 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 13:43, Andrei Alexandrescu wrote:


 Totally agreed. One issue now is that Walter has converged briskly on
 the simplistic conclusion "no more steenking breakages" instead of
 learning git and designing a useful process around it. That way the
 process remains broken instead of being identified as the main issue and
 fixed. I have advocated privately in much stronger terms than I could
 afford publicly that we must fix the process and exercise good judgment
 about changing the language - all to no avail. "No more breakages" is
 like taking an aspirin for the fever caused by gangrene.

 I think with dread about what's coming when completing shared will be on
 the table. We'll be looking at not breaking code that was by definition
 broken.


Thanks again for acknowledging these problems. I do really hope what we 
can see some changes in this area.

-- 
/Jacob Carlborg



 Nov 28 2012



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-27 22:23, Walter Bright wrote:


 I understand what you're saying, but the counterpoint is we lost half
 the D community when D2 broke D1 code. We still have at least one major
 D1 user that still finds it impractical to upgrade to D2.

 It is unbelievably frustrating for people to have their code break with
 each new release, have older projects all invalidated, with few willing
 to do the maintenance work to bring them back on line.


In the keynote for the latest Ruby on Rails conference. The original 
creator of Ruby on Rails goes out and say: Yes, Rails 4 will break 
existing code. He also says that progress is good and one should keep a 
young mind.

I can assure you that Ruby on Rails has vastly more commercial 
developers than D has.

What I mean is that that process of improving the language most not stop 
and should always continue. It's just the process how that is made that 
makes the big difference.

-- 
/Jacob Carlborg



 Nov 28 2012



 next sibling parent reply "Paulo Pinto" <pjmlp progtools.org>  writes:


On Wednesday, 28 November 2012 at 09:26:55 UTC, Jacob Carlborg 
wrote:

 On 2012-11-27 22:23, Walter Bright wrote:


 I understand what you're saying, but the counterpoint is we 
 lost half
 the D community when D2 broke D1 code. We still have at least 
 one major
 D1 user that still finds it impractical to upgrade to D2.

 It is unbelievably frustrating for people to have their code 
 break with
 each new release, have older projects all invalidated, with 
 few willing
 to do the maintenance work to bring them back on line.


 In the keynote for the latest Ruby on Rails conference. The 
 original creator of Ruby on Rails goes out and say: Yes, Rails 
 4 will break existing code. He also says that progress is good 
 and one should keep a young mind.
...


Lets see if the Ruby community will take it better than the 
Python one has.

--
Paulo



 Nov 28 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 10:53, Paulo Pinto wrote:


 Lets see if the Ruby community will take it better than the Python one has.


Ruby on Rails still updates older version. Rails 3.2.8 is the current 
stable release. But since the first release of Rails 3 the Rails 2.3 
branch has received new updates and releases. Ruby on Rails, actually 
most of the Ruby projects, use a sane versioning scheme that makes it 
easier to handle code breakage.

-- 
/Jacob Carlborg



 Nov 28 2012



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/28/12 4:26 AM, Jacob Carlborg wrote:

 On 2012-11-27 22:23, Walter Bright wrote:


 I understand what you're saying, but the counterpoint is we lost half
 the D community when D2 broke D1 code. We still have at least one major
 D1 user that still finds it impractical to upgrade to D2.

 It is unbelievably frustrating for people to have their code break with
 each new release, have older projects all invalidated, with few willing
 to do the maintenance work to bring them back on line.


 In the keynote for the latest Ruby on Rails conference. The original
 creator of Ruby on Rails goes out and say: Yes, Rails 4 will break
 existing code. He also says that progress is good and one should keep a
 young mind.

 I can assure you that Ruby on Rails has vastly more commercial
 developers than D has.

 What I mean is that that process of improving the language most not stop
 and should always continue. It's just the process how that is made that
 makes the big difference.


Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060 
code :o).

Andrei



 Nov 28 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-28 13:46, Andrei Alexandrescu wrote:


 Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
 code :o).


I've talked about that before. D doesn't have a versioning scheme that 
makes any sense. It's just a number that gets incremented without any 
meaning. Except that a greater number indicates a later version. Also 
changes to the language, compiler, runtime and standard library always 
happen in the same release.

-- 
/Jacob Carlborg



 Nov 28 2012



 next sibling parent reply 1100110 <0b1100110 gmail.com>  writes:


On 11/28/2012 07:31 AM, Jacob Carlborg wrote:

 On 2012-11-28 13:46, Andrei Alexandrescu wrote:


 Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
 code :o).


 I've talked about that before. D doesn't have a versioning scheme that
 makes any sense. It's just a number that gets incremented without any
 meaning. Except that a greater number indicates a later version. Also
 changes to the language, compiler, runtime and standard library always
 happen in the same release.


I must admit that I'm surprised that no one has simply forked the 
project in order to apply their own versioning scheme to it.



 Nov 28 2012



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 28 November 2012 at 17:19:48 UTC, 1100110 wrote:

 On 11/28/2012 07:31 AM, Jacob Carlborg wrote:

 On 2012-11-28 13:46, Andrei Alexandrescu wrote:


 Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks 
 Rails 3.060
 code :o).


 I've talked about that before. D doesn't have a versioning 
 scheme that
 makes any sense. It's just a number that gets incremented 
 without any
 meaning. Except that a greater number indicates a later 
 version. Also
 changes to the language, compiler, runtime and standard 
 library always
 happen in the same release.


 I must admit that I'm surprised that no one has simply forked 
 the project in order to apply their own versioning scheme to it.


Well, D has been forked in the past (tango vs phobos) but it 
tended to make things even worse.



 Nov 28 2012



  parent  1100110 <0b1100110 gmail.com>  writes:


On 11/28/2012 11:49 AM, deadalnix wrote:

 On Wednesday, 28 November 2012 at 17:19:48 UTC, 1100110 wrote:

 On 11/28/2012 07:31 AM, Jacob Carlborg wrote:

 On 2012-11-28 13:46, Andrei Alexandrescu wrote:


 Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
 code :o).


 I've talked about that before. D doesn't have a versioning scheme that
 makes any sense. It's just a number that gets incremented without any
 meaning. Except that a greater number indicates a later version. Also
 changes to the language, compiler, runtime and standard library always
 happen in the same release.


 I must admit that I'm surprised that no one has simply forked the
 project in order to apply their own versioning scheme to it.


 Well, D has been forked in the past (tango vs phobos) but it tended to
 make things even worse.


Well I was thinking more along the lines of prevent breaking changes but 
I suppose you are right.

And now that you mention it, I suppose I've forked the GC as well...



 Nov 28 2012



prev sibling  parent  "Rob T" <rob ucora.com>  writes:


On Wednesday, 28 November 2012 at 13:31:36 UTC, Jacob Carlborg 
wrote:

 On 2012-11-28 13:46, Andrei Alexandrescu wrote:


 Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 
 3.060
 code :o).


 I've talked about that before. D doesn't have a versioning 
 scheme that makes any sense. It's just a number that gets 
 incremented without any meaning. Except that a greater number 
 indicates a later version. Also changes to the language, 
 compiler, runtime and standard library always happen in the 
 same release.


When people refer to D1, D2, D3, and eventually D4, etc, what 
they should be referring to is a major version upgrade that will 
purposefully contain breaking changes, and will inevitably 
introduce a whole new set of bugs.

Usually increments to a minor version mean increasing stability, 
not decreasing stability or unknown stability!

Major version increments means that breaking changes may be 
introduced on purpose for a good reason, and it may mean new bugs 
will be introduced as well.

The major/minor versioning system has been in use for ages. Many 
people rely on it, including myself. I use different packages, 
that I purposely keep at a certain major revision number, and I 
always happily update to the next minor version, because it 
introduces bug fixes, not breaking changes. I only migrate to the 
next major revision only after it has matured over a few minor 
increments.

Again, sometimes I jump on the next breaking major revision, 
because it's for non-critical work, or for a new feature that I 
really need today. The point is that I can identify what is 
breaking and what is not just by looking at the version number, 
and I can pick and choose which version I think fits the 
stability model for my situation.

In any case, I did suggest re-thinking how a language can be made 
to change in significant ways over time. The major.minor version 
concept may be too simplistic for this, but holy crap, it's at 
least a good start since we don't even have that!

Something has to change, and it has to change quickly.

--rt



 Nov 28 2012



prev sibling  parent  Nick Treleaven <ntrel-public yahoo.co.uk>  writes:


On 26/11/2012 19:59, Walter Bright wrote:

 On 11/27/2012 5:52 AM, David Nadlinger wrote:

 I agree, and if I remember previous discussions on the subject
 correctly, it seems like only Walter is in favor of upholding the
 current restrictions of "alias" parameters to symbols. I simply do not
 see a point in pushing compiler implementation details on the user like
 that – for the programmer, a type is a type is a type…

 Walter, do you have an example of a situation where the alias parameter
 restriction would be beneficial?  (for the D code involved, I don't mean
 the few lines of code avoided in the compiler)


 In any case, it will break a great deal of existing code to change  that
 behavior.


I agree we shouldn't change the semantics of alias parameters now, 
particularly as breakages wouldn't be detectable. That would be horrible 
for any affected code.

However, if at some point we want to improve the situation, we could add 
a different syntax, e.g. using 'auto':

template Foo(auto Param)
...
template Foo(T)

auto template parameters would accept anything, including built-in 
types. auto template parameters should therefore be considered less 
specialized than type parameters like T in the Foo(T) template. So 
Foo!int and Foo!MyStruct would instantiate Foo(T), not Foo(auto Param).



 Nov 29 2012