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