www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++ guys hate static_if?

reply "DypthroposTheImposter" <mcbracket gmail.com> writes:
        See the static_if paper here:

http://isocpp.org/forums

Under the post "constraints and static if" there is a link to a
document about
static_if

https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg

       Are they full of it? Has it caused the problems they mention
in
D?
Mar 08 2013
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter 
wrote:
        See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg

       Are they full of it? Has it caused the problems they 
 mention
 in
 D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate static if (along with a third guy). There seems to be a lot of strawman arguments in this paper.
Mar 08 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/8/2013 5:19 PM, Brad Anderson wrote:
 On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
       Are they full of it? Has it caused the problems they mention
 in
 D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate static if (along with a third guy). There seems to be a lot of strawman arguments in this paper.
Many of the criticisms in the paper are addressed by our positive experience with static if in D.
Mar 08 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 08, 2013 at 07:50:26PM -0800, Walter Bright wrote:
 On 3/8/2013 5:19 PM, Brad Anderson wrote:
On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
      Are they full of it? Has it caused the problems they mention
in
D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate static if (along with a third guy). There seems to be a lot of strawman arguments in this paper.
Many of the criticisms in the paper are addressed by our positive experience with static if in D.
I didn't read the paper, but I have to say that static if in D has been extremely, extremely useful in my code. Now that I've become acquianted with it, I can't live without it. It's pretty much a necessity when writing heavily-templated code. But given C++'s broken template design, I can see why its value may not have been appreciated by some people. D may still have its warts, but in terms of being a "better C++", I think it has done a superb job, especially in the area of templates and compile-time mechanisms. Static if + CTFE + sane template syntax = readable template code = total win for D over C++. T -- Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".
Mar 08 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 9 March 2013 at 03:50:29 UTC, Walter Bright wrote:
 On 3/8/2013 5:19 PM, Brad Anderson wrote:
 On Saturday, 9 March 2013 at 00:48:59 UTC, 
 DypthroposTheImposter wrote:
 Are they full of it? Has it caused the problems they mention 
 in D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate static if (along with a third Guy). There seems to be a lot of strawman arguments in this paper.
Many of the criticisms in the paper are addressed by our positive experience with static if in D.
Since C++ is so deeply etched with C's previous limitations and problems, it also got the preprocessor, which when you think about it does the same thing (until you've actually used it); Now you've got preprocessor #ifdef's mixed with compile time execution determining what should and shouldn't be compiled, it is a very messy pile of crud. Even IF static_if gets working and accepted in C++, it's core requirement to be 100% backwards compatible with all previous code ensures it's growth will forever be hampered. Maybe if they could get their template system fixed (which will never happen) then static_if would work much better. God I hate C++.
Mar 08 2013
prev sibling next sibling parent reply "Jouko Koski" <joukokoskispam101 netti.fi> writes:
"Walter Bright"  wrote:

 Many of the criticisms in the paper are addressed by our positive 
 experience with static if in D.
Sometimes I do find it confusing that { does or does not introduce a new scope in a very similar-looking contexts. -- Jouko
Mar 09 2013
parent reply "simendsjo" <simendsjo gmail.com> writes:
On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:
 "Walter Bright"  wrote:

 Many of the criticisms in the paper are addressed by our 
 positive experience with static if in D.
Sometimes I do find it confusing that { does or does not introduce a new scope in a very similar-looking contexts.
Is there more constructs than static if that doesn't create a scope?
Mar 09 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 9 March 2013 at 09:41:42 UTC, simendsjo wrote:
 On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:
 "Walter Bright"  wrote:

 Many of the criticisms in the paper are addressed by our 
 positive experience with static if in D.
Sometimes I do find it confusing that { does or does not introduce a new scope in a very similar-looking contexts.
Is there more constructs than static if that doesn't create a scope?
version, debug, release, const/immutable/inout/static/whatever{} .
Mar 09 2013
parent "simendsjo" <simendsjo gmail.com> writes:
On Saturday, 9 March 2013 at 09:52:55 UTC, deadalnix wrote:
 On Saturday, 9 March 2013 at 09:41:42 UTC, simendsjo wrote:
 On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:
 "Walter Bright"  wrote:

 Many of the criticisms in the paper are addressed by our 
 positive experience with static if in D.
Sometimes I do find it confusing that { does or does not introduce a new scope in a very similar-looking contexts.
Is there more constructs than static if that doesn't create a scope?
version, debug, release, const/immutable/inout/static/whatever{} .
I see const++ as well as property as qualifiers and don't assume a new scope. Didn't think of version++ though :)
Mar 09 2013
prev sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 9 March 2013 at 09:41:42 UTC, simendsjo wrote:
 On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:
 "Walter Bright"  wrote:

 Many of the criticisms in the paper are addressed by our 
 positive experience with static if in D.
Sometimes I do find it confusing that { does or does not introduce a new scope in a very similar-looking contexts.
Is there more constructs than static if that doesn't create a scope?
"Labeled scopes" (ironically) don't create scopes. Eg: //---- some_label: { int a; //Code code code } a = 5; goto some_label; //---- That doesn't actually create a new scope, and that assignement is legal game. This is from the official documentation, so it is not a bug. I can't, for the life of me, understand why it is that way, in particular, since it deviates from C. I see it as a "never better, sometimes worst" approach. I've tried to ask about it before, but I best, the answer I got was "works as documented", but still have no idea on the why :/ ??? And since goto is "evil", I think very few people care, so getting any kind of activity about this is hard.
Mar 09 2013
prev sibling next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 03/09/13 05:34, H. S. Teoh wrote:
 On Fri, Mar 08, 2013 at 07:50:26PM -0800, Walter Bright wrote:
 On 3/8/2013 5:19 PM, Brad Anderson wrote:
 On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
      Are they full of it? Has it caused the problems they mention
 in
 D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate static if (along with a third guy). There seems to be a lot of strawman arguments in this paper.
Many of the criticisms in the paper are addressed by our positive experience with static if in D.
I didn't read the paper, but I have to say that static if in D has been extremely, extremely useful in my code. Now that I've become acquianted with it, I can't live without it. It's pretty much a necessity when writing heavily-templated code. But given C++'s broken template design, I can see why its value may not have been appreciated by some people. D may still have its warts, but in terms of being a "better C++", I think it has done a superb job, especially in the area of templates and compile-time mechanisms. Static if + CTFE + sane template syntax = readable template code = total win for D over C++.
Let me quote a paragraph from that paper:
 Being a new and realtively simple-to-use new feature, static_if would un-
 doubtedly be used by many who have no need for the relatively small increme-
 natal improvement in performance offered. The library writers for which such
 techniques really are important, already have to tools and skills needed.
No skilled Real Programmer would ever use a language feature that was simple to use. Seriously though, they point out several problems, some of which are C++ context specific (like mixing CPP w/ static-if and lack of introspection). Other mentioned issues are not real problems in practice, or not even problems at all. What's left is: - static-if not creating scopes /is/ confusing, but what would be a better alternative? - (static-)if in templates or as template constraints - a) prevents pre-instantiation verification - true, applies to D, but not really a big problem, assuming sane application of static-if, b) make constraint-based overloading ugly and fragile - true, something better is needed for D too. But until that exists, careful use of constraints mostly works. artur
Mar 09 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 03/09/2013 03:15 AM, Artur Skawina wrote:

   - static-if not creating scopes /is/ confusing, but what would be a 
better
     alternative?
I am surprised that << and >> are never mentioned: static_if >> void foo(); << Problem solved. ;) Ali
Mar 09 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 9 March 2013 at 17:51:31 UTC, Ali Çehreli wrote:
 On 03/09/2013 03:15 AM, Artur Skawina wrote:

   - static-if not creating scopes /is/ confusing, but what
would be a better
     alternative?
I am surprised that << and >> are never mentioned: static_if >> void foo(); << Problem solved. ;) Ali
static if(condition) « void foo(); » Let's do it with style ;)
Mar 09 2013
next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 03/09/2013 12:10 PM, deadalnix wrote:
 On Saturday, 9 March 2013 at 17:51:31 UTC, Ali Çehreli wrote:
 On 03/09/2013 03:15 AM, Artur Skawina wrote:

 - static-if not creating scopes /is/ confusing, but what
would be a better
 alternative?
I am surprised that << and >> are never mentioned: static_if >> void foo(); << Problem solved. ;) Ali
static if(condition) « void foo(); » Let's do it with style ;)
I love how the second set show up in two different styles on my computer.
Mar 09 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 9 March 2013 at 18:23:29 UTC, 1100110 wrote:
 I love how the second set show up in two different styles on my 
 computer.
This is not different style, this is different chars. << >> != « » .
Mar 09 2013
parent 1100110 <0b1100110 gmail.com> writes:
On 03/09/2013 12:30 PM, deadalnix wrote:
 On Saturday, 9 March 2013 at 18:23:29 UTC, 1100110 wrote:
 I love how the second set show up in two different styles on my computer.
This is not different style, this is different chars. << >> != « » .
Yes, but my email client did not display them( « » ) as the same character. They showed up as two distinct characters( « >> (we're totally going to pretend that's one character)), which amused me since your comment was "let's do it with style."
Mar 09 2013
prev sibling next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 03/09/2013 10:10 AM, deadalnix wrote:

 static_if >>
 void foo();
 <<

 Problem solved. ;)

 Ali
static if(condition) « void foo(); » Let's do it with style ;)
Ha ha! :) I remembered about those characters as well but only after posting mine. Ali
Mar 09 2013
prev sibling parent reply Hans Uhlig <hans.uhlig teamaol.com> writes:
On 3/9/2013 10:10 AM, deadalnix wrote:
 On Saturday, 9 March 2013 at 17:51:31 UTC, Ali Çehreli wrote:
 On 03/09/2013 03:15 AM, Artur Skawina wrote:

   - static-if not creating scopes /is/ confusing, but what
would be a better
     alternative?
I am surprised that << and >> are never mentioned: static_if >> void foo(); << Problem solved. ;) Ali
static if(condition) « void foo(); » Let's do it with style ;)
So now I am going to need a unicode keyboard or a massive list of unicode code points.
Mar 12 2013
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-03-12, 23:49, Hans Uhlig wrote:

 On 3/9/2013 10:10 AM, deadalnix wrote:
 On Saturday, 9 March 2013 at 17:51:31 UTC, Ali =C3=87ehreli wrote:
 On 03/09/2013 03:15 AM, Artur Skawina wrote:

   - static-if not creating scopes /is/ confusing, but what
would be a better
     alternative?
I am surprised that << and >> are never mentioned: static_if >> void foo(); << Problem solved. ;) Ali
static if(condition) =C2=AB void foo(); =C2=BB Let's do it with style ;)
So now I am going to need a unicode keyboard or a massive list of =
 unicode code points.
Or we could make the language latex-aware, and use \guillemotleft and \guillemotright. That would also solve the problem of operators =E2=88=83= , =E2=88=9A, =E2=8A=82, =E2=88=A9, =E2=88=99, =E2=A8=AF, and the like. I kid, of course. But it might be worth having a look at Fortress for their representational and editable forms, as well as the wealth of overloadable operators. -- = Simen
Mar 20 2013
prev sibling parent reply =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
Note that there will be a teleconference Tuesday with one important point:
 "Discuss whether to continue work on static if, or to focus work on
concepts lite."
See:
https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/AMVFwQGgS3c

I'm pointing that in case Alexandrescu and Walter didn't know and want to
defend their paper.

Joel Lamotte
Mar 09 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/9/13 1:10 PM, Klaim - Joël Lamotte wrote:
 Note that there will be a teleconference Tuesday with one important point:
 "Discuss whether to continue work on static if, or to focus work on
 concepts lite."
 See:
 https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/AMVFwQGgS3c

 I'm pointing that in case Alexandrescu and Walter didn't know and want
 to defend their paper.

 Joel Lamotte
Thanks, Joel. Andrei
Mar 09 2013
prev sibling parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 09/03/2013 11:15, Artur Skawina wrote:
 Seriously though, they point out several problems, some of which are C++
 context specific (like mixing CPP w/ static-if and lack of introspection).
 Other mentioned issues are not real problems in practice, or not even
 problems at all.

 What's left is:
   - static-if not creating scopes/is/  confusing, but what would be a better
     alternative?
Isn't it only confusing to newbies? It's not hard to learn and recognize.
   - (static-)if in templates or as template constraints -
      a) prevents pre-instantiation verification - true, applies to D, but
           not really a big problem, assuming sane application of static-if,
Maybe a concept-based static if would work for C++? That would allow pre-instantiation verification, but still allow flexible code. The concept test would only allow concept features within the static if branch.
      b) make constraint-based overloading ugly and fragile - true, something
           better is needed for D too. But until that exists, careful use
           of constraints mostly works.
Mar 11 2013
parent reply "Jouko Koski" <joukokoskispam101 netti.fi> writes:
"Nick Treleaven" wrote:
 On 09/03/2013 11:15, Artur Skawina wrote:
   - static-if not creating scopes/is/  confusing, but what would be a 
 better
     alternative?
Isn't it only confusing to newbies? It's not hard to learn and recognize.
Maybe. This is just precisely the way how it all begun in C/C++. -- Jouko
Mar 11 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/11/2013 07:55 PM, Jouko Koski wrote:
 "Nick Treleaven" wrote:
 On 09/03/2013 11:15, Artur Skawina wrote:
   - static-if not creating scopes/is/  confusing, but what would be
a > better
     alternative?
Isn't it only confusing to newbies? It's not hard to learn and recognize.
Maybe. This is just precisely the way how it all begun in C/C++.
Actually, in D, static if creates its own scopes for declarations made inside the static if condition.
Mar 11 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
 Actually, in D, static if creates its own scopes for declarations made
 inside the static if condition.
No, it doesn't, and it would be _way_ less useful if it did, particularly with regards to struct and class definitions. Take this code, for instance, import std.stdio; static if(true)    int var = 7; else    string var = 12; void main() {    int i = var;    static if(is(typeof(var) == int))        int j = 22;    else        float j;    writeln(j); } It compiles just fine and prints 22. Both the static if at module-level and the one in the function declare variables which are used outside of the static if blocks. static if does _not_ create a new scope. And putting braces around the static if bodies has no effect on the scoping either. - Jonathan M Davis
Mar 11 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/11/2013 09:19 PM, Jonathan M Davis wrote:
 On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
 Actually, in D, static if creates its own scopes for declarations made
 inside the static if condition.
No, it doesn't,
Yes it does.
 and it would be _way_ less useful if it did,
I don't think so.
 particularly with
 regards to struct and class definitions. Take this code, for instance,

 import std.stdio;

 static if(true)
      int var = 7;
 else
      string var = 12;

 void main()
 {
      int i = var;

      static if(is(typeof(var) == int))
          int j = 22;
      else
          float j;

      writeln(j);
 }

 It compiles just fine and prints 22. Both the static if at module-level and the
 one in the function declare variables which are used outside of the static if
 blocks. static if does _not_ create a new scope. And putting braces around the
 static if bodies has no effect on the scoping either.

 ...
What is the point? Your example code does not make any declaration inside the static if condition.
Mar 11 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Mar 11, 2013 at 10:31:53PM +0100, Timon Gehr wrote:
 On 03/11/2013 09:19 PM, Jonathan M Davis wrote:
On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
Actually, in D, static if creates its own scopes for declarations
made inside the static if condition.
No, it doesn't,
Yes it does.
Actually, it doesn't, scarily enough: import std.stdio; void main() { int[string] x; //float x; static if (is(typeof(x) S : T[U], T, U)) { writeln(S.stringof); writeln(T.stringof); writeln(U.stringof); } writeln(S.stringof); // <-- this compiles, and works!! } The last writeln will fail to compile if x's type is changed to float (as in the commented out line). Meaning that the definitions of S, T, U "leak" past the scope of the static if. Which makes the semantics of the code very unclear, because whether or not it even compiles depends on how the static if condition turns out. :-/ T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Mar 11 2013
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 11 March 2013 at 22:08:10 UTC, H. S. Teoh wrote:
 On Mon, Mar 11, 2013 at 10:31:53PM +0100, Timon Gehr wrote:
 On 03/11/2013 09:19 PM, Jonathan M Davis wrote:
On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
Actually, in D, static if creates its own scopes for 
declarations
made inside the static if condition.
No, it doesn't,
Yes it does.
Actually, it doesn't, scarily enough: import std.stdio; void main() { int[string] x; //float x; static if (is(typeof(x) S : T[U], T, U)) { writeln(S.stringof); writeln(T.stringof); writeln(U.stringof); } writeln(S.stringof); // <-- this compiles, and works!! } The last writeln will fail to compile if x's type is changed to float (as in the commented out line). Meaning that the definitions of S, T, U "leak" past the scope of the static if. Which makes the semantics of the code very unclear, because whether or not it even compiles depends on how the static if condition turns out. :-/ T
I think that's bug material. The "is" definition should end at the end of that block.
Mar 11 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/11/2013 11:15 PM, monarch_dodra wrote:
 ...

 I think that's bug material. The "is" definition should end at the end
 of that block.
http://d.puremagic.com/issues/show_bug.cgi?id=9693
Mar 11 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/11/2013 11:06 PM, H. S. Teoh wrote:
 On Mon, Mar 11, 2013 at 10:31:53PM +0100, Timon Gehr wrote:
 On 03/11/2013 09:19 PM, Jonathan M Davis wrote:
 On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
 Actually, in D, static if creates its own scopes for declarations
 made inside the static if condition.
No, it doesn't,
Yes it does.
Actually, it doesn't, scarily enough: import std.stdio; void main() { int[string] x; //float x; static if (is(typeof(x) S : T[U], T, U)) { writeln(S.stringof); writeln(T.stringof); writeln(U.stringof); } writeln(S.stringof); // <-- this compiles, and works!! } The last writeln will fail to compile if x's type is changed to float (as in the commented out line). Meaning that the definitions of S, T, U "leak" past the scope of the static if. Which makes the semantics of the code very unclear, because whether or not it even compiles depends on how the static if condition turns out. :-/ T
Wtf. :) void main() { int[string] x; static if (is(typeof(x) S : T[U], T, U)) { } pragma(msg, S, " ", T, " ", U); } I have checked again and the documentation actually does not specify this. It just contains suggestive examples.
Mar 11 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 11 March 2013 at 21:31:53 UTC, Timon Gehr wrote:
 On 03/11/2013 09:19 PM, Jonathan M Davis wrote:
 On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
 Actually, in D, static if creates its own scopes for 
 declarations made
 inside the static if condition.
No, it doesn't,
Yes it does.
No... It doesn't. He just showed you.
 and it would be _way_ less useful if it did,
I don't think so.
Half the code in phobos would be broken.
 particularly with
 regards to struct and class definitions. Take this code, for 
 instance,

 import std.stdio;

 static if(true)
     int var = 7;
 else
     string var = 12;

 void main()
 {
     int i = var;

     static if(is(typeof(var) == int))
         int j = 22;
     else
         float j;

     writeln(j);
 }

 It compiles just fine and prints 22. Both the static if at 
 module-level and the
 one in the function declare variables which are used outside 
 of the static if
 blocks. static if does _not_ create a new scope. And putting 
 braces around the
 static if bodies has no effect on the scoping either.

 ...
What is the point? Your example code does not make any declaration inside the static if condition.
What *are* you talking about??? I can count 4 declarations in 2 static ifs? What is your definition of "declaration" and "scope". There's a misunderstanding somewhere here. Can YOU show us an example where there is a declaration that is scoped?
Mar 11 2013
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 11 March 2013 at 22:12:46 UTC, monarch_dodra wrote:
 On Monday, 11 March 2013 at 21:31:53 UTC, Timon Gehr wrote:
 On 03/11/2013 09:19 PM, Jonathan M Davis wrote:
 On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
 Actually, in D, static if creates its own scopes for 
 declarations made
 inside the static if condition.
No, it doesn't,
Yes it does.
No... It doesn't. He just showed you. [...] There's a misunderstanding somewhere here. Can YOU show us an example where there is a declaration that is scoped?
OOhhhh!!! "Condition" Right.
Mar 11 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, March 11, 2013 23:12:45 monarch_dodra wrote:
 What *are* you talking about??? I can count 4 declarations in 2
 static ifs? What is your definition of "declaration" and "scope".
 
 There's a misunderstanding somewhere here. Can YOU show us an
 example where there is a declaration that is scoped?
Exactly. Every single line in those static ifs is a variable declaration, and not a one of them creates a new scope, or the code wouldn't compile. I don't understand how Timon can think that there are no declarations in that code. There's clearly a fundamental misunderstanding and/or miscommunication here. - Jonathan M Davis
Mar 11 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 11 Mar 2013 20:53:59 -0400
"Jonathan M Davis" <jmdavisProg gmx.com> wrote:

 On Monday, March 11, 2013 23:12:45 monarch_dodra wrote:
 What *are* you talking about??? I can count 4 declarations in 2
 static ifs? What is your definition of "declaration" and "scope".
 
 There's a misunderstanding somewhere here. Can YOU show us an
 example where there is a declaration that is scoped?
Exactly. Every single line in those static ifs is a variable declaration, and not a one of them creates a new scope, or the code wouldn't compile. I don't understand how Timon can think that there are no declarations in that code. There's clearly a fundamental misunderstanding and/or miscommunication here.
Timon was talking about declarations in the static if's *condition*, not the body.
Mar 11 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Mar 11, 2013 at 09:03:20PM -0400, Nick Sabalausky wrote:
 On Mon, 11 Mar 2013 20:53:59 -0400
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote:
 
 On Monday, March 11, 2013 23:12:45 monarch_dodra wrote:
 What *are* you talking about??? I can count 4 declarations in 2
 static ifs? What is your definition of "declaration" and "scope".
 
 There's a misunderstanding somewhere here. Can YOU show us an
 example where there is a declaration that is scoped?
Exactly. Every single line in those static ifs is a variable declaration, and not a one of them creates a new scope, or the code wouldn't compile. I don't understand how Timon can think that there are no declarations in that code. There's clearly a fundamental misunderstanding and/or miscommunication here.
Timon was talking about declarations in the static if's *condition*, not the body.
Regardless, I have shown that even declarations in the condition leaks past the body of the static if. T -- Don't modify spaghetti code unless you can eat the consequences.
Mar 11 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 00:54:18 UTC, Jonathan M Davis wrote:
 On Monday, March 11, 2013 23:12:45 monarch_dodra wrote:
 What *are* you talking about??? I can count 4 declarations in 2
 static ifs? What is your definition of "declaration" and 
 "scope".
 
 There's a misunderstanding somewhere here. Can YOU show us an
 example where there is a declaration that is scoped?
Exactly. Every single line in those static ifs is a variable declaration, and not a one of them creates a new scope, or the code wouldn't compile. I don't understand how Timon can think that there are no declarations in that code. There's clearly a fundamental misunderstanding and/or miscommunication here. - Jonathan M Davis
Yes, you totally missed the point where he was saying in *condition*
Mar 11 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/12/13, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 There's clearly a fundamental misunderstanding
Clearly 10 people in here haven't read his sentence properly where he said "in the static if **condition**", and not the static if *block*.
Mar 11 2013
parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 12 March 2013 at 01:00:58 UTC, Andrej Mitrovic wrote:
 On 3/12/13, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 There's clearly a fundamental misunderstanding
Clearly 10 people in here haven't read his sentence properly where he said "in the static if **condition**", and not the static if *block*.
That maybe so, he clearly changed the subject. We did discovered a bug because of it.
Mar 11 2013
prev sibling next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 11 March 2013 at 21:31:53 UTC, Timon Gehr wrote:
 On 03/11/2013 09:19 PM, Jonathan M Davis wrote:
 On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
 Actually, in D, static if creates its own scopes for 
 declarations made
 inside the static if condition.
No, it doesn't,
Yes it does.
No, it doesn't.
 and it would be _way_ less useful if it did,
I don't think so.
Oh? Examples inside the TDPL would break as the inner scopes would be hidden and thereby inaccessible. TDPL pg. 279 [quote] [code] template Select(bool cond, T1, T2) { static if (cond) { alias T1 Type; } else { alias T2 Type; } } unittest { alias Select!(false, int, string).Type MyType; static assert(is(MyType == string)); } [/code] [/quote] Plus it's part of the spec. TDPL pg. 69 [quote] Peeling Braces: There's a glaring oddity about the transmogrify example. See, the numeric type is introduced inside a pair of { and } braces. As such, it should be visible only locally inside that scope (and consequently invisible to the enclosing function), thus foiling our entire plan quite thoroughly. Such behavior would also render the promised static if statement practically useless. For that reason, the static if uses braces for [i]grouping[/i] but not for [i]scoping[/i]. As far as scope and visibility are concerned, static if peels the outermost braces away, if any (they are not required when you have only one controlled statement; out example above uses them only out of stylistic obsession). If you do want braces, just add another pair: [code] void main(){ static if (real.sizeof > double.sizeof) {{ auto maximorum = real.max; writefln("Really big numbers - up to %s!", maximorum); }} ... /* maximorum is invisible here */ ... } [/code] [/quote]
Mar 11 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 March 2013 at 22:42:26 UTC, Era Scarecrow wrote:
 On Monday, 11 March 2013 at 21:31:53 UTC, Timon Gehr wrote:
 On 03/11/2013 09:19 PM, Jonathan M Davis wrote:
 On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
 Actually, in D, static if creates its own scopes for 
 declarations made
 inside the static if condition.
No, it doesn't,
Yes it does.
No, it doesn't.
 and it would be _way_ less useful if it did,
I don't think so.
Oh? Examples inside the TDPL would break as the inner scopes would be hidden and thereby inaccessible.
Good, now check the meaning of condition.
Mar 11 2013
prev sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Monday, 11 March 2013 at 21:31:53 UTC, Timon Gehr wrote:
     static if(is(typeof(var) == int))
         int j = 22;
What is the point? Your example code does not make any declaration inside the static if condition.
I'm not sure what your definition of declaration is, but that looks like one to me, with instantiation of course.
Mar 11 2013
prev sibling parent reply "Don" <turnyourkidsintocash nospam.com> writes:
On Saturday, 9 March 2013 at 03:50:29 UTC, Walter Bright wrote:
 On 3/8/2013 5:19 PM, Brad Anderson wrote:
 On Saturday, 9 March 2013 at 00:48:59 UTC, 
 DypthroposTheImposter wrote:
      Are they full of it? Has it caused the problems they 
 mention
 in
 D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate static if (along with a third guy). There seems to be a lot of strawman arguments in this paper.
Many of the criticisms in the paper are addressed by our positive experience with static if in D.
I think the hard-to-analyze argument is a good one. I've created an enhancement for some analysis we could do without too much work: http://d.puremagic.com/issues/show_bug.cgi?id=9715 (I think my bug report shows a bigger problem with static if, than is reported in the paper; the problems arise only when you have two static ifs in the same scope).
Mar 14 2013
parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 03/14/13 10:26, Don wrote:
 On Saturday, 9 March 2013 at 03:50:29 UTC, Walter Bright wrote:
 On 3/8/2013 5:19 PM, Brad Anderson wrote:
 On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
      Are they full of it? Has it caused the problems they mention
 in
 D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate static if (along with a third guy). There seems to be a lot of strawman arguments in this paper.
Many of the criticisms in the paper are addressed by our positive experience with static if in D.
I think the hard-to-analyze argument is a good one. I've created an enhancement for some analysis we could do without too much work: http://d.puremagic.com/issues/show_bug.cgi?id=9715 (I think my bug report shows a bigger problem with static if, than is reported in the paper; the problems arise only when you have two static ifs in the same scope).
The gain from such checks would be minimal. Eg "return x.toray;". artur
Mar 14 2013
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 14 March 2013 at 11:04:59 UTC, Artur Skawina wrote:
 On 03/14/13 10:26, Don wrote:
 On Saturday, 9 March 2013 at 03:50:29 UTC, Walter Bright wrote:
 On 3/8/2013 5:19 PM, Brad Anderson wrote:
 On Saturday, 9 March 2013 at 00:48:59 UTC, 
 DypthroposTheImposter wrote:
      Are they full of it? Has it caused the problems they 
 mention
 in
 D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate static if (along with a third guy). There seems to be a lot of strawman arguments in this paper.
Many of the criticisms in the paper are addressed by our positive experience with static if in D.
I think the hard-to-analyze argument is a good one. I've created an enhancement for some analysis we could do without too much work: http://d.puremagic.com/issues/show_bug.cgi?id=9715 (I think my bug report shows a bigger problem with static if, than is reported in the paper; the problems arise only when you have two static ifs in the same scope).
The gain from such checks would be minimal. Eg "return x.toray;". artur
I've already found plenty of such bugs in phobos, and wouldn't be surprised if this was one of its bigger sources of bugs. Sure, phobos is template and static "super heavy", given it is more or less the D-STL, but still. If the compiler can statically determine that a template branch simply *can't* compile, then the code should be turned down. Having to instantiate a template just to check to make sure it is semantically correct is a huge pain.
Mar 14 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 11:05 AM, monarch_dodra wrote:
 Having to instantiate a template just to check to make sure it is
 semantically correct is a huge pain.
I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests. Andrei
Mar 14 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 11:38 AM, Andrei Alexandrescu wrote:
 On 3/14/13 11:05 AM, monarch_dodra wrote:
 Having to instantiate a template just to check to make sure it is
 semantically correct is a huge pain.
I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests.
Uhm sorry for the repetition. Wrote this note in two quanta with a break between them :o). Andrei
Mar 14 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 14 March 2013 at 15:38:53 UTC, Andrei Alexandrescu 
wrote:
 On 3/14/13 11:05 AM, monarch_dodra wrote:
 Having to instantiate a template just to check to make sure it 
 is
 semantically correct is a huge pain.
I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests. Andrei
The same argument can be made when talking about dynamic vs static typing. This is usualy much better to have the compiler smash your mistake right into your face than discovering with a unittest much latter. I don't say that unittest are useless, but why rely on unittest when the machine can do the job for you ?
Mar 14 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 11:50 AM, deadalnix wrote:
 On Thursday, 14 March 2013 at 15:38:53 UTC, Andrei Alexandrescu wrote:
 On 3/14/13 11:05 AM, monarch_dodra wrote:
 Having to instantiate a template just to check to make sure it is
 semantically correct is a huge pain.
I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests. Andrei
The same argument can be made when talking about dynamic vs static typing.
And it has been made indeed. The question is on agreeing or not with specifics. The stereotypical argument in favor of dynamic typing goes as follows: Q: Does static typing detect all bugs? A: No. Q: Then unittests are necessary. A: Correct. Q: So if static typing is insufficient, why not rely on unittests alone to do all checking? It's also bothersome for some people to obey types, annotate stuff etc. A: There are still errors that can be better detected with static checking, and many dynamic programs that work by accident etc. Q: ... I agree or don't agree ...
 This is usualy much better to have the compiler smash your mistake right
 into your face than discovering with a unittest much latter.
I don't think so.
 I don't say that unittest are useless, but why rely on unittest when the
 machine can do the job for you ?
In both cases the machine does the work. My argument is that adding an additional layer of typing on top of templates caters to people who want to ship code that has literally zero testing. That's not a priority as far as I'm concerned. Andrei
Mar 14 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 14 March 2013 at 16:48:29 UTC, Andrei Alexandrescu 
wrote:
 And it has been made indeed. The question is on agreeing or not 
 with specifics. The stereotypical argument in favor of dynamic 
 typing goes as follows:

 Q: Does static typing detect all bugs?

 A: No.

 Q: Then unittests are necessary.

 A: Correct.

 Q: So if static typing is insufficient, why not rely on 
 unittests alone to do all checking? It's also bothersome for 
 some people to obey types, annotate stuff etc.

 A: There are still errors that can be better detected with 
 static checking, and many dynamic programs that work by 
 accident etc.
I see we agree this is the same problem materialized in another form. I find it rather weird that you conclude different things when the problem is the same in the first place.
 I don't say that unittest are useless, but why rely on 
 unittest when the
 machine can do the job for you ?
In both cases the machine does the work. My argument is that adding an additional layer of typing on top of templates caters to people who want to ship code that has literally zero testing. That's not a priority as far as I'm concerned.
I have other benefit, as the capability for the compiler to give understandable error message instead of a wall of template errors. This is clearly not a priority anyway. We should stop building on foundation that aren't solid or everything will collapse.
Mar 14 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 12:54 PM, deadalnix wrote:
 On Thursday, 14 March 2013 at 16:48:29 UTC, Andrei Alexandrescu wrote:
 And it has been made indeed. The question is on agreeing or not with
 specifics. The stereotypical argument in favor of dynamic typing goes
 as follows:

 Q: Does static typing detect all bugs?

 A: No.

 Q: Then unittests are necessary.

 A: Correct.

 Q: So if static typing is insufficient, why not rely on unittests
 alone to do all checking? It's also bothersome for some people to obey
 types, annotate stuff etc.

 A: There are still errors that can be better detected with static
 checking, and many dynamic programs that work by accident etc.
I see we agree this is the same problem materialized in another form. I find it rather weird that you conclude different things when the problem is the same in the first place.
Very simple. Traditionally there's two crucial epochs known as compilation time and run time. (There's some minor distinctions like link time etc.) The whole notion of concepts and other type systems for templates is predicated on three crucial epochs: library compilation time, library user compilation time, and run time. The logic goes, someone writes a generic library and wants to distribute it to users. Users shouldn't ever see bugs caused by e.g. typos in the library. So the crowd that use meta-type systems is formed of library writers who want to distribute libraries without ever instantiating them. I don't think that's a good crowd to cater for. I've been surprised to figure how many people don't get this flow, or only have a vague image of it. Although meta-types are arguably "the right thing" to do, they're a lot less attractive once it's clear what scenarios they help. Andrei
Mar 14 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 14 March 2013 at 17:07:16 UTC, Andrei Alexandrescu 
wrote:
 Very simple. Traditionally there's two crucial epochs known as 
 compilation time and run time. (There's some minor distinctions 
 like link time etc.) The whole notion of concepts and other 
 type systems for templates is predicated on three crucial 
 epochs: library compilation time, library user compilation 
 time, and run time. The logic goes, someone writes a generic 
 library and wants to distribute it to users. Users shouldn't 
 ever see bugs caused by e.g. typos in the library.

 So the crowd that use meta-type systems is formed of library 
 writers who want to distribute libraries without ever 
 instantiating them. I don't think that's a good crowd to cater 
 for.

 I've been surprised to figure how many people don't get this 
 flow, or only have a vague image of it. Although meta-types are 
 arguably "the right thing" to do, they're a lot less attractive 
 once it's clear what scenarios they help.
It is the very same reasoning. Meta-library developers are humans and make mistakes. Forgetting to cover instantiating some corner case in this example. If this won't compile, this bug won't persist all the way down to the user of this library, exactly the one we care most for.
Mar 14 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
14-Mar-2013 21:07, Andrei Alexandrescu пишет:
 On 3/14/13 12:54 PM, deadalnix wrote:
[snip]
 Q: So if static typing is insufficient, why not rely on unittests
 alone to do all checking? It's also bothersome for some people to obey
 types, annotate stuff etc.

 A: There are still errors that can be better detected with static
 checking, and many dynamic programs that work by accident etc.
I see we agree this is the same problem materialized in another form. I find it rather weird that you conclude different things when the problem is the same in the first place.
Very simple. Traditionally there's two crucial epochs known as compilation time and run time. (There's some minor distinctions like link time etc.) The whole notion of concepts and other type systems for templates is predicated on three crucial epochs: library compilation time, library user compilation time, and run time. The logic goes, someone writes a generic library and wants to distribute it to users. Users shouldn't ever see bugs caused by e.g. typos in the library. So the crowd that use meta-type systems is formed of library writers who want to distribute libraries without ever instantiating them. I don't think that's a good crowd to cater for. I've been surprised to figure how many people don't get this flow, or only have a vague image of it. Although meta-types are arguably "the right thing" to do, they're a lot less attractive once it's clear what scenarios they help.
Maybe we then should help people that routinely instantiate their templates to see if they compile. Say add a library artifact tryInstantiate: auto foo(...)(...); static assert(tryInstantiate!(foo, TypesForFirstArg!(...), TypesForSecond!(foo, ...),...); Inspired by the ubiquitously common foreach(type; TypeTuple!(A,B,C)){ ...} unit test pattern. -- Dmitry Olshansky
Mar 14 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 10:20 AM, Dmitry Olshansky wrote:
 Maybe we then should help people that routinely instantiate their templates to
 see if they compile.
We already have a tool to do this: dmd -cov test.d
Mar 14 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/14/2013 08:46 PM, Walter Bright wrote:
 On 3/14/2013 10:20 AM, Dmitry Olshansky wrote:
 Maybe we then should help people that routinely instantiate their
 templates to
 see if they compile.
We already have a tool to do this: dmd -cov test.d
But it does not work. See this recent D.learn thread: http://forum.dlang.org/thread/wwjaeexnyaeqnqsqydte forum.dlang.org
Mar 14 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 12:51 PM, Timon Gehr wrote:
 On 03/14/2013 08:46 PM, Walter Bright wrote:
 On 3/14/2013 10:20 AM, Dmitry Olshansky wrote:
 Maybe we then should help people that routinely instantiate their
 templates to
 see if they compile.
We already have a tool to do this: dmd -cov test.d
But it does not work. See this recent D.learn thread: http://forum.dlang.org/thread/wwjaeexnyaeqnqsqydte forum.dlang.org
-cov works fine for templates containing executable code.
Mar 14 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/14/2013 09:11 PM, Walter Bright wrote:
 On 3/14/2013 12:51 PM, Timon Gehr wrote:
 On 03/14/2013 08:46 PM, Walter Bright wrote:
 On 3/14/2013 10:20 AM, Dmitry Olshansky wrote:
 Maybe we then should help people that routinely instantiate their
 templates to
 see if they compile.
We already have a tool to do this: dmd -cov test.d
But it does not work. See this recent D.learn thread: http://forum.dlang.org/thread/wwjaeexnyaeqnqsqydte forum.dlang.org
-cov works fine for templates containing executable code.
Then it is not what Dmitry was asking for. Anyway -cov is near-useless for me because it does not support string mixins (execution attributed to wrong code line) and executable code coming from template mixins (sometimes counted, sometimes not).
Mar 14 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 2:01 PM, Timon Gehr wrote:
 Anyway -cov is near-useless for me
 because it does not support string mixins (execution attributed to wrong code
 line) and executable code coming from template mixins (sometimes counted,
 sometimes not).
Please file bugzilla entries for these.
Mar 14 2013
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
14-Mar-2013 23:46, Walter Bright пишет:
 On 3/14/2013 10:20 AM, Dmitry Olshansky wrote:
 Maybe we then should help people that routinely instantiate their
 templates to
 see if they compile.
We already have a tool to do this: dmd -cov test.d
No it's not. It's I'm out of words to even begin to describe how it doesn't do what's needed in this case. To start 'dmd -cov test.d' doesn't instantiate all of templates (or generate code to do so) with the right sets of types auto-magically. -- Dmitry Olshansky
Mar 14 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 12:53 PM, Dmitry Olshansky wrote:
 No it's not.
 It's I'm out of words to even begin to describe how it doesn't do what's needed
 in this case. To start 'dmd -cov test.d' doesn't instantiate all of templates
 (or generate code to do so) with the right sets of types auto-magically.
It helps by showing which paths were run by the testing.
Mar 14 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Mar-2013 00:12, Walter Bright пишет:
 On 3/14/2013 12:53 PM, Dmitry Olshansky wrote:
 No it's not.
 It's I'm out of words to even begin to describe how it doesn't do
 what's needed
 in this case. To start 'dmd -cov test.d' doesn't instantiate all of
 templates
 (or generate code to do so) with the right sets of types auto-magically.
It helps by showing which paths were run by the testing.
It doesn't show which types ended up in each of template instantiation. This is a critical piece of information. The way around that would be having a separate file per combination of type and run each with cov separately then use external tool to analyze and aggregate the logs. Far, far from 'having a tool to do this'. The aspect of running separate tests is even more frustrating as the fact compiler knows all of the relevant info already. -- Dmitry Olshansky
Mar 14 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 12:53 PM, Dmitry Olshansky wrote:
 No it's not.
 It's I'm out of words to even begin to describe how it doesn't do what's needed
 in this case. To start 'dmd -cov test.d' doesn't instantiate all of templates
 (or generate code to do so) with the right sets of types auto-magically.
For the following program: ---------test.d------------- import core.stdc.stdio; public import std.whatever; int main() { printf("Success!\n"); return 0; } ---------------------------- Try compiling: dmd -cov test.d std\whatever -unittest and examine std-whatever.lst. We can do a lot, lot better before we need something better than -cov.
Mar 14 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Mar-2013 00:27, Walter Bright пишет:
 On 3/14/2013 12:53 PM, Dmitry Olshansky wrote:
 No it's not.
 It's I'm out of words to even begin to describe how it doesn't do
 what's needed
 in this case. To start 'dmd -cov test.d' doesn't instantiate all of
 templates
 (or generate code to do so) with the right sets of types auto-magically.
For the following program: ---------test.d------------- import core.stdc.stdio; public import std.whatever; int main() { printf("Success!\n"); return 0; } ---------------------------- Try compiling: dmd -cov test.d std\whatever -unittest and examine std-whatever.lst. We can do a lot, lot better before we need something better than -cov.
Point taken. That doesn't detract us from: a) fixing issues with -cov It counts time a LOC is executed. Would nice to add instantations counter (determined at compile time) as well so as to see if declarations are all covered. That + CTFE-only counted as 0. b) unifying template fuzzy testing in Phobos We have lots of these wheels reinvented across Phobos alone. c) prototyping other higher-level tools to aid debugging generic code -- Dmitry Olshansky
Mar 14 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 15, 2013 at 12:37:00AM +0400, Dmitry Olshansky wrote:
 15-Mar-2013 00:27, Walter Bright пишет:
[...]
For the following program:
---------test.d-------------
import core.stdc.stdio;
public import std.whatever;

int main()
{
     printf("Success!\n");
     return 0;
}
----------------------------

Try compiling:

     dmd -cov test.d std\whatever -unittest

and examine std-whatever.lst.

We can do a lot, lot better before we need something better than
-cov.
Point taken. That doesn't detract us from: a) fixing issues with -cov It counts time a LOC is executed. Would nice to add instantations counter (determined at compile time) as well so as to see if declarations are all covered. That + CTFE-only counted as 0. b) unifying template fuzzy testing in Phobos We have lots of these wheels reinvented across Phobos alone. c) prototyping other higher-level tools to aid debugging generic code
[...] d) factor out useful test data/objects (e.g. ranges of particular types, with particular sets of data, etc.) into a common place so that they can be reused across unittests. T -- "Maybe" is a strange word. When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.
Mar 14 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 14 March 2013 at 20:46:11 UTC, H. S. Teoh wrote:
 b) unifying template fuzzy testing in Phobos
 
 We have lots of these wheels reinvented across Phobos alone.
By the way, is there any theoretical way to separate compilation errors due to failed constraints from errors due to errors in template body? I can't imagine one now, but if it is possible, some really cool unit test helper module can be written (In fact I almost started writing it when remembered about this requirement)
Mar 14 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 4:37 PM, Dmitry Olshansky wrote:
 Point taken. That doesn't detract us from:
 a) fixing issues with -cov
Yes please (are there bugzilla entries etc)?
 It counts time a LOC is executed. Would nice to add instantations
 counter (determined at compile time) as well so as to see if
 declarations are all covered. That + CTFE-only counted as 0.
Not getting this. Example?
 b) unifying template fuzzy testing in Phobos

 We have lots of these wheels reinvented across Phobos alone.
Like those dummy ranges in std.algorithm?
 c) prototyping other higher-level tools to aid debugging generic code
Yeppers! Andrei
Mar 14 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 14, 2013 17:58:44 Andrei Alexandrescu wrote:
 b) unifying template fuzzy testing in Phobos
 
 We have lots of these wheels reinvented across Phobos alone.
Like those dummy ranges in std.algorithm?
I had improved versions of those that I was working on which were more flexible and thorough. I really should get back to sorting those out and submit them (IIRC, I was blocked by bugs which have now been fixed). - Jonathan M Davis
Mar 14 2013
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Mar-2013 01:58, Andrei Alexandrescu пишет:
 On 3/14/13 4:37 PM, Dmitry Olshansky wrote:
 Point taken. That doesn't detract us from:
 a) fixing issues with -cov
Yes please (are there bugzilla entries etc)?
template powerup(T) //usable as template mixin too { //imagine more constraints static if(size_t.sizeof == 4) alias bleh = blah; else alias bleh = oldBlah; //... } Now first mixin template don't get counted at all (even code within). Then declarations are ignored and you'll never know which ones were ever looked at.
 It counts time a LOC is executed. Would nice to add instantations
 counter (determined at compile time) as well so as to see if
 declarations are all covered. That + CTFE-only counted as 0.
Not getting this. Example?
See above.
 b) unifying template fuzzy testing in Phobos

 We have lots of these wheels reinvented across Phobos alone.
Like those dummy ranges in std.algorithm?
Yes. We might as well provide a good hardy set of these as std.testing.mockup or smth like that.
 c) prototyping other higher-level tools to aid debugging generic code
Yeppers!
It seems like a good application for DSL + CTFE. Even if CTFE is too inefficient ATM for large tests a standalone tool could be prototyped with exactly same D code. Now that I'm saying it I'll probably prototype one just for fun :)
 Andrei
-- Dmitry Olshansky
Mar 14 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 11:36 PM, Dmitry Olshansky wrote:
 15-Mar-2013 01:58, Andrei Alexandrescu пишет:
 On 3/14/13 4:37 PM, Dmitry Olshansky wrote:
 Point taken. That doesn't detract us from:
 a) fixing issues with -cov
Yes please (are there bugzilla entries etc)?
template powerup(T) //usable as template mixin too { //imagine more constraints static if(size_t.sizeof == 4) alias bleh = blah; else alias bleh = oldBlah; //... } Now first mixin template don't get counted at all (even code within). Then declarations are ignored and you'll never know which ones were ever looked at.
-cov only counts executable lines. The above are not executable - I don't see any way to make them work with -cov.
Mar 14 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Mar-2013 10:47, Walter Bright пишет:
 On 3/14/2013 11:36 PM, Dmitry Olshansky wrote:
 15-Mar-2013 01:58, Andrei Alexandrescu пишет:
 On 3/14/13 4:37 PM, Dmitry Olshansky wrote:
 Point taken. That doesn't detract us from:
 a) fixing issues with -cov
Yes please (are there bugzilla entries etc)?
template powerup(T) //usable as template mixin too { //imagine more constraints static if(size_t.sizeof == 4) alias bleh = blah; else alias bleh = oldBlah; //... } Now first mixin template don't get counted at all (even code within). Then declarations are ignored and you'll never know which ones were ever looked at.
-cov only counts executable lines. The above are not executable - I don't see any way to make them work with -cov.
The information can be trivially collected during semantic analysis of declarations. How to merge this compile-time info with run-time one as in -cov is a another question. I'd try outputting some table into object file (special section etc.) and then -cov would use it to mark non-executable code. -- Dmitry Olshansky
Mar 14 2013
parent "Don" <turnyourkidsintocash nospam.com> writes:
On Friday, 15 March 2013 at 06:51:15 UTC, Dmitry Olshansky wrote:
 15-Mar-2013 10:47, Walter Bright пишет:
 On 3/14/2013 11:36 PM, Dmitry Olshansky wrote:
 15-Mar-2013 01:58, Andrei Alexandrescu пишет:
 On 3/14/13 4:37 PM, Dmitry Olshansky wrote:
 Point taken. That doesn't detract us from:
 a) fixing issues with -cov
Yes please (are there bugzilla entries etc)?
template powerup(T) //usable as template mixin too { //imagine more constraints static if(size_t.sizeof == 4) alias bleh = blah; else alias bleh = oldBlah; //... } Now first mixin template don't get counted at all (even code within). Then declarations are ignored and you'll never know which ones were ever looked at.
-cov only counts executable lines. The above are not executable - I don't see any way to make them work with -cov.
The information can be trivially collected during semantic analysis of declarations. How to merge this compile-time info with run-time one as in -cov is a another question. I'd try outputting some table into object file (special section etc.) and then -cov would use it to mark non-executable code.
We need to do something like this. Without some kind of "instantiation coverage", it's practically impossible to be confident that your D templates are correct. Actually I'm not certain that it needs to be the same file as -cov. I mean, you might want to check that you have 100% template instantiation coverage, before you do your runtime tests. It can be interesting to know that a line in a function template is instantiated 10 times, and run 3 times, whereas another line is run 857 times, but only instantiated once.
Mar 15 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 1:27 PM, Walter Bright wrote:
 We can do a lot, lot better before we need something better than -cov.
A proposal to improve the use of -cov: http://d.puremagic.com/issues/show_bug.cgi?id=9726
Mar 15 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 3:53 PM, Dmitry Olshansky wrote:
 It's I'm out of words to even begin to describe how it doesn't do what's
 needed in this case. To start 'dmd -cov test.d' doesn't instantiate all
 of templates (or generate code to do so) with the right sets of types
 auto-magically.
You are well understood. What a coverage test does help with is show you there is code that has never been instantiated. Andrei
Mar 14 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 14 March 2013 at 17:07:16 UTC, Andrei Alexandrescu 
wrote:
 Very simple. Traditionally there's two crucial epochs known as 
 compilation time and run time. (There's some minor distinctions 
 like link time etc.) The whole notion of concepts and other 
 type systems for templates is predicated on three crucial 
 epochs: library compilation time, library user compilation 
 time, and run time. The logic goes, someone writes a generic 
 library and wants to distribute it to users. Users shouldn't 
 ever see bugs caused by e.g. typos in the library.
I'm not sure if you are thinking I'm really stupid here.
 So the crowd that use meta-type systems is formed of library 
 writers who want to distribute libraries without ever 
 instantiating them. I don't think that's a good crowd to cater 
 for.

 I've been surprised to figure how many people don't get this 
 flow, or only have a vague image of it. Although meta-types are 
 arguably "the right thing" to do, they're a lot less attractive 
 once it's clear what scenarios they help.
Let me demonstrate with an actual example : libd-llvm/libd/src/d/parser/ambiguous.d(126): Error: no property 'bar' for type 'Lexer', did you mean 'r'? libd-llvm/libd/src/d/parser/statement.d(392): Error: template instance d.parser.statement.parseStatement!(Lexer).parseStatement.parseDeclarationOrExpres ion!(__dgliteral27, Lexer) error instantiating libd-llvm/libd/src/d/parser/statement.d(406): instantiated from here: parseStatement!(Lexer) libd-llvm/libd/src/d/parser/expression.d(652): instantiated from here: parseBlock!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(208): instantiated from here: parsePrimaryExpression!(Lexer) libd-llvm/libd/src/d/parser/identifier.d(83): ... (11 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/statement.d(406): Error: template instance d.parser.statement.parseStatement!(Lexer) error instantiating libd-llvm/libd/src/d/parser/expression.d(652): instantiated from here: parseBlock!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(208): instantiated from here: parsePrimaryExpression!(Lexer) libd-llvm/libd/src/d/parser/identifier.d(83): instantiated from here: parseTemplateArguments!(Lexer) libd-llvm/libd/src/d/parser/identifier.d(22): ... (10 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/expression.d(652): Error: template instance d.parser.statement.parseBlock!(Lexer) error instantiating libd-llvm/libd/src/d/parser/dtemplate.d(208): instantiated from here: parsePrimaryExpression!(Lexer) libd-llvm/libd/src/d/parser/identifier.d(83): instantiated from here: parseTemplateArguments!(Lexer) libd-llvm/libd/src/d/parser/identifier.d(22): instantiated from here: parseBuiltIdentifier!(Lexer) libd-llvm/libd/src/d/parser/type.d(56): ... (9 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(208): Error: template instance d.parser.expression.parsePrimaryExpression!(Lexer) error instantiating libd-llvm/libd/src/d/parser/identifier.d(83): instantiated from here: parseTemplateArguments!(Lexer) libd-llvm/libd/src/d/parser/identifier.d(22): instantiated from here: parseBuiltIdentifier!(Lexer) libd-llvm/libd/src/d/parser/type.d(56): instantiated from here: parseIdentifier!(Lexer) libd-llvm/libd/src/d/parser/type.d(16): ... (8 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/identifier.d(83): Error: template instance d.parser.dtemplate.parseTemplateArguments!(Lexer) error instantiating libd-llvm/libd/src/d/parser/identifier.d(22): instantiated from here: parseBuiltIdentifier!(Lexer) libd-llvm/libd/src/d/parser/type.d(56): instantiated from here: parseIdentifier!(Lexer) libd-llvm/libd/src/d/parser/type.d(16): instantiated from here: parseBasicType!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(112): ... (7 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/identifier.d(22): Error: template instance d.parser.identifier.parseBuiltIdentifier!(Lexer) error instantiating libd-llvm/libd/src/d/parser/type.d(56): instantiated from here: parseIdentifier!(Lexer) libd-llvm/libd/src/d/parser/type.d(16): instantiated from here: parseBasicType!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(112): instantiated from here: parseType!(cast(ParseMode)0, Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(68): ... (6 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/type.d(56): Error: template instance d.parser.identifier.parseIdentifier!(Lexer) error instantiating libd-llvm/libd/src/d/parser/type.d(16): instantiated from here: parseBasicType!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(112): instantiated from here: parseType!(cast(ParseMode)0, Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(68): instantiated from here: parseTypeParameter!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(46): ... (5 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/type.d(16): Error: template instance d.parser.type.parseBasicType!(Lexer) error instantiating libd-llvm/libd/src/d/parser/dtemplate.d(112): instantiated from here: parseType!(cast(ParseMode)0, Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(68): instantiated from here: parseTypeParameter!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(46): instantiated from here: parseTemplateParameter!(Lexer) libd-llvm/libd/src/d/parser/dfunction.d(51): ... (4 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(112): Error: template instance d.parser.type.parseType!(cast(ParseMode)0, Lexer) error instantiating libd-llvm/libd/src/d/parser/dtemplate.d(68): instantiated from here: parseTypeParameter!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(46): instantiated from here: parseTemplateParameter!(Lexer) libd-llvm/libd/src/d/parser/dfunction.d(51): instantiated from here: parseTemplateParameters!(Lexer) libd-llvm/libd/src/d/parser/declaration.d(362): ... (3 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(68): Error: template instance d.parser.dtemplate.parseTypeParameter!(Lexer) error instantiating libd-llvm/libd/src/d/parser/dtemplate.d(46): instantiated from here: parseTemplateParameter!(Lexer) libd-llvm/libd/src/d/parser/dfunction.d(51): instantiated from here: parseTemplateParameters!(Lexer) libd-llvm/libd/src/d/parser/declaration.d(362): instantiated from here: parseFunction!(FunctionDeclaration, Lexer, string,Type) libd-llvm/libd/src/d/parser/declaration.d(70): ... (2 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(46): Error: template instance d.parser.dtemplate.parseTemplateParameter!(Lexer) error instantiating libd-llvm/libd/src/d/parser/dfunction.d(51): instantiated from here: parseTemplateParameters!(Lexer) libd-llvm/libd/src/d/parser/declaration.d(362): instantiated from here: parseFunction!(FunctionDeclaration, Lexer, string,Type) libd-llvm/libd/src/d/parser/declaration.d(70): instantiated from here: parseTypedDeclaration!(Lexer) libd-llvm/libd/src/d/parser/dmodule.d(40): ... (1 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/dfunction.d(51): Error: template instance d.parser.dtemplate.parseTemplateParameters!(Lexer) error instantiating libd-llvm/libd/src/d/parser/declaration.d(362): instantiated from here: parseFunction!(FunctionDeclaration, Lexer, string,Type) libd-llvm/libd/src/d/parser/declaration.d(70): instantiated from here: parseTypedDeclaration!(Lexer) libd-llvm/libd/src/d/parser/dmodule.d(40): instantiated from here: parseDeclaration!(Lexer) libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/declaration.d(362): Error: template instance d.parser.dfunction.parseFunction!(FunctionDeclaration, Lexer, string,Type) error instantiating libd-llvm/libd/src/d/parser/declaration.d(70): instantiated from here: parseTypedDeclaration!(Lexer) libd-llvm/libd/src/d/parser/dmodule.d(40): instantiated from here: parseDeclaration!(Lexer) libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/declaration.d(70): Error: template instance d.parser.declaration.parseTypedDeclaration!(Lexer) error instantiating libd-llvm/libd/src/d/parser/dmodule.d(40): instantiated from here: parseDeclaration!(Lexer) libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/dmodule.d(40): Error: template instance d.parser.declaration.parseDeclaration!(Lexer) error instantiating libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/base.d(14): Error: template instance d.parser.dmodule.parseModule!(Lexer) error instantiating src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) src/sdc/sdc.d(54): Error: template instance d.parser.base.parse!(Lexer) error instantiating libd-llvm/libd/src/d/parser/ambiguous.d(126): Error: no property 'bar' for type 'Lexer', did you mean 'r'? libd-llvm/libd/src/d/parser/statement.d(392): Error: template instance d.parser.statement.parseStatement!(Lexer).parseStatement.parseDeclarationOrExpres ion!(__dgliteral27, Lexer) error instantiating libd-llvm/libd/src/d/parser/statement.d(406): instantiated from here: parseStatement!(Lexer) libd-llvm/libd/src/d/parser/expression.d(652): instantiated from here: parseBlock!(Lexer) libd-llvm/libd/src/d/parser/dtemplate.d(208): instantiated from here: parsePrimaryExpression!(Lexer) libd-llvm/libd/src/d/parser/identifier.d(83): ... (11 instantiations, -v to show) ... libd-llvm/libd/src/d/parser/base.d(14): instantiated from here: parseModule!(Lexer) src/sdc/sdc.d(54): instantiated from here: parse!(Lexer) libd-llvm/libd/src/d/parser/statement.d(406): Error: template instance d.parser.statement.parseStatement!(Lexer) error instantiating make: *** [bin/sdc] Erreur 1 Yes I added the bar on purpose in some heavily templated code. You concentrate too much on theses people that want to ship code without using it. They'll do it anyway. And that make even more sense from the lib user perspective, as having the compiler vomit kilometers of internals of a lib is usually not helpful (this happen a lot with phobos).
Mar 14 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 1:37 PM, deadalnix wrote:
 On Thursday, 14 March 2013 at 17:07:16 UTC, Andrei Alexandrescu wrote:
 Very simple. Traditionally there's two crucial epochs known as
 compilation time and run time. (There's some minor distinctions like
 link time etc.) The whole notion of concepts and other type systems
 for templates is predicated on three crucial epochs: library
 compilation time, library user compilation time, and run time. The
 logic goes, someone writes a generic library and wants to distribute
 it to users. Users shouldn't ever see bugs caused by e.g. typos in the
 library.
I'm not sure if you are thinking I'm really stupid here.
Being wrong doesn't make one stupid.
 So the crowd that use meta-type systems is formed of library writers
 who want to distribute libraries without ever instantiating them. I
 don't think that's a good crowd to cater for.

 I've been surprised to figure how many people don't get this flow, or
 only have a vague image of it. Although meta-types are arguably "the
 right thing" to do, they're a lot less attractive once it's clear what
 scenarios they help.
Let me demonstrate with an actual example :
[snip]
 Yes I added the bar on purpose in some heavily templated code. You
 concentrate too much on theses people that want to ship code without
 using it. They'll do it anyway.

 And that make even more sense from the lib user perspective, as having
 the compiler vomit kilometers of internals of a lib is usually not
 helpful (this happen a lot with phobos).
Template constraints are D's solution to that issue. I agree it's not perfect, but I think dollar for dollar it's better than concepts. Andrei
Mar 14 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 14 March 2013 at 17:53:42 UTC, Andrei Alexandrescu 
wrote:
 On 3/14/13 1:37 PM, deadalnix wrote:
 On Thursday, 14 March 2013 at 17:07:16 UTC, Andrei 
 Alexandrescu wrote:
 Very simple. Traditionally there's two crucial epochs known as
 compilation time and run time. (There's some minor 
 distinctions like
 link time etc.) The whole notion of concepts and other type 
 systems
 for templates is predicated on three crucial epochs: library
 compilation time, library user compilation time, and run 
 time. The
 logic goes, someone writes a generic library and wants to 
 distribute
 it to users. Users shouldn't ever see bugs caused by e.g. 
 typos in the
 library.
I'm not sure if you are thinking I'm really stupid here.
Being wrong doesn't make one stupid.
I may be wrong, but certainly not because I don't make the difference between compile time and run time.
 Template constraints are D's solution to that issue. I agree 
 it's not perfect, but I think dollar for dollar it's better 
 than concepts.
No they aren't, because it would only skip the top most lines and replace the error by something like impossible to find method blah. With something like concept, I'd have something like in case of eroneous template : file:line: Error: concept Blah don't have member blah. Or in the case of unmatched constraint : file:line: Error: template Blah except a concept argument of meta-type Foo, Bar given. And in both cases you can avoid the dreaded wall of error.
Mar 14 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 10:25 PM, deadalnix wrote:
 On Thursday, 14 March 2013 at 17:53:42 UTC, Andrei Alexandrescu wrote:
 Template constraints are D's solution to that issue. I agree it's not perfect,
 but I think dollar for dollar it's better than concepts.
No they aren't, because it would only skip the top most lines and replace the error by something like impossible to find method blah. With something like concept, I'd have something like in case of eroneous template : file:line: Error: concept Blah don't have member blah.
D also allows you to build custom error messages.
Mar 14 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 10:37 AM, deadalnix wrote:
 Let me demonstrate with an actual example :

 libd-llvm/libd/src/d/parser/ambiguous.d(126): Error: no property 'bar' for type
 'Lexer', did you mean 'r'?
This wouldn't have been detected under the proposed scheme, because it is a semantic error, not a syntactic one.
Mar 14 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 14 Mar 2013 11:38:52 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 3/14/13 11:05 AM, monarch_dodra wrote:
 Having to instantiate a template just to check to make sure it is
 semantically correct is a huge pain.
I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests.
What the hell is this, a JS/Python forum all of a sudden? You're literally making the exact same argument as "We don't need no steenkin' static type checking." On Thu, 14 Mar 2013 13:07:16 -0400 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 
 Very simple. Traditionally there's two crucial epochs known as 
 compilation time and run time. (There's some minor distinctions like 
 link time etc.) The whole notion of concepts and other type systems
 for templates is predicated on three crucial epochs: library
 compilation time, library user compilation time, and run time. The
 logic goes, someone writes a generic library and wants to distribute
 it to users. Users shouldn't ever see bugs caused by e.g. typos in
 the library.
 
 So the crowd that use meta-type systems is formed of library writers
 who want to distribute libraries without ever instantiating them. I
 don't think that's a good crowd to cater for.
 
 I've been surprised to figure how many people don't get this flow, or 
 only have a vague image of it. Although meta-types are arguably "the 
 right thing" to do, they're a lot less attractive once it's clear
 what scenarios they help.
 
That's because the flow is completely wrong. Particularly so in the context of a static-typed language. Where do I start?: - The branch of the discussion you're replying in has nothing to do with meta-types and yet you seem to be arguing on the false dichotomy of "Introduce meta-types vs no static checks on templates without instantiation". Please check the link in Don's post a few replies up. - "...library writers who want to distribute libraries without ever instantiating them..." is a hyperbolic strawman. Do you really expect us to believe that you and other respectable coders, let alone ordinary coders, *never* miss an instantiation? Of course not, and we both know that. So don't insult us by trying to paint this out as some "it only helps/encourages the lazy" bullshit. - We're talking a static-typed language here. The philosophy that "it's better to catch a whole class of errors as early regardless of whether the code in question gets used than to delay the check until a point where it may or may not get caught" is already a given. We're not Python here.
Mar 14 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 1:43 PM, Nick Sabalausky wrote:
 On Thu, 14 Mar 2013 11:38:52 -0400
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:

 On 3/14/13 11:05 AM, monarch_dodra wrote:
 Having to instantiate a template just to check to make sure it is
 semantically correct is a huge pain.
I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests.
What the hell is this, a JS/Python forum all of a sudden? You're literally making the exact same argument as "We don't need no steenkin' static type checking."
No. Andrei
Mar 14 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 14 Mar 2013 13:50:33 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 3/14/13 1:43 PM, Nick Sabalausky wrote:
 On Thu, 14 Mar 2013 11:38:52 -0400
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:

 On 3/14/13 11:05 AM, monarch_dodra wrote:
 Having to instantiate a template just to check to make sure it is
 semantically correct is a huge pain.
I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests.
What the hell is this, a JS/Python forum all of a sudden? You're literally making the exact same argument as "We don't need no steenkin' static type checking."
No.
Yes.
Mar 14 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 14, 2013 13:07:16 Andrei Alexandrescu wrote:
 Very simple. Traditionally there's two crucial epochs known as
 compilation time and run time. (There's some minor distinctions like
 link time etc.) The whole notion of concepts and other type systems for
 templates is predicated on three crucial epochs: library compilation
 time, library user compilation time, and run time. The logic goes,
 someone writes a generic library and wants to distribute it to users.
 Users shouldn't ever see bugs caused by e.g. typos in the library.
 
 So the crowd that use meta-type systems is formed of library writers who
 want to distribute libraries without ever instantiating them. I don't
 think that's a good crowd to cater for.
 
 I've been surprised to figure how many people don't get this flow, or
 only have a vague image of it. Although meta-types are arguably "the
 right thing" to do, they're a lot less attractive once it's clear what
 scenarios they help.
The main problem is not people who don't unit test their templates but the fact that it's pretty much impossible to cover every possible instantiation of a template, and so it can be pretty easy to miss stuff. Better unit testing will obviously cover more, and on the whole, I think that that's a fine solution, but it would also be nice if the compiler caught more. However, given that it's pretty much a given that the compiler won't catch the stuff that's actually going to be a problem (e.g. a type with weird characteristics due to alias this or whatnot ends up not working correctly with a template), I'm not sure that it the compiler really can be improved to help out in any meaningful way. In general, the more the compiler can catch for you at compile time, the better, but there are definite limits to that even with a very smart compiler (and the smarter the compiler, the more likely it is to be buggy). - Jonathan M Davis
Mar 14 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 2:29 PM, Jonathan M Davis wrote:
 The main problem is not people who don't unit test their templates but the
 fact that it's pretty much impossible to cover every possible instantiation of
 a template, and so it can be pretty easy to miss stuff.
Concepts don't do that either. I do agree we could and should do a better job at testing templates against bare minimum structures that pass their constraints (e.g. test input range algorithms with true input range, which are indeed one-pass). Again, concepts won't help there either - it's not like we claim to support input ranges and then call .save against them. That's not a frequent bug. Andrei
Mar 14 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 14 Mar 2013 17:54:52 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 it's not like we claim to support input ranges and
 then call .save against them.
Although this is getting OT, we do kind of do that in a way: It's very common for a range to be a struct rather than a class. In fact, std.range/algorithm has generally been considered to work better with struct ranges with class ranges being a secondary thought. And yet, due the the nature of structs, all it takes to effectively ".save" an InputRange (or at least attempt to) is this: struct MyInputRange {...} void foo(R)(R r) if(isInputRange!R) { auto s = r; } ... foo(MyInputRange()); That implicitly does the equivalent of ".save" on a mere InputRange *twice*. The result, of course, is completely dependent on the input range in question.
Mar 14 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 14 March 2013 at 23:52:59 UTC, Nick Sabalausky wrote:
 On Thu, 14 Mar 2013 17:54:52 -0400
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 it's not like we claim to support input ranges and
 then call .save against them.
Although this is getting OT, we do kind of do that in a way: It's very common for a range to be a struct rather than a class. In fact, std.range/algorithm has generally been considered to work better with struct ranges with class ranges being a secondary thought. And yet, due the the nature of structs, all it takes to effectively ".save" an InputRange (or at least attempt to) is this: struct MyInputRange {...} void foo(R)(R r) if(isInputRange!R) { auto s = r; } ... foo(MyInputRange()); That implicitly does the equivalent of ".save" on a mere InputRange *twice*. The result, of course, is completely dependent on the input range in question.
Passing range by value is completely undefined, which is IMO a big weak spot of ranges.
Mar 14 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Mar-2013 06:43, deadalnix пишет:
 On Thursday, 14 March 2013 at 23:52:59 UTC, Nick Sabalausky wrote:
 On Thu, 14 Mar 2013 17:54:52 -0400
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

[snip]
 That implicitly does the equivalent of ".save" on a mere InputRange
 *twice*. The result, of course, is completely dependent on the input
 range in question.
Passing range by value is completely undefined, which is IMO a big weak spot of ranges.
What can be done in the mean time is stating somewhere prominent this: Given InputRanges a & b: 1. a = b; //now 'a' can only be *either* an alias of 'b' or 'a' is a copy of 'b' 2. a = move(b); //now a is the only copy (the only alias ;)) 3. a = b.save(); //now a is guaranteed to be a shallow copy By copy here it's implied that range preserves iteration state. The underlying values may be changed elsewhere. There could be some argument to make 1 always do 3 and trim it to 2 rules. But ehm, sorry, classes as ranges can't do that so we are stuck. If I had to choose I'd drop the current OOP support of D in favor of simplifying things (only half-joking) :) -- Dmitry Olshansky
Mar 15 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Mar-2013 15:27, Dmitry Olshansky пишет:
 15-Mar-2013 06:43, deadalnix пишет:
 On Thursday, 14 March 2013 at 23:52:59 UTC, Nick Sabalausky wrote:
 On Thu, 14 Mar 2013 17:54:52 -0400
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

[snip]
 That implicitly does the equivalent of ".save" on a mere InputRange
 *twice*. The result, of course, is completely dependent on the input
 range in question.
Passing range by value is completely undefined, which is IMO a big weak spot of ranges.
What can be done in the mean time is stating somewhere prominent this: Given InputRanges a & b:
Forward obviously.
 1. a = b; //now 'a' can only be *either* an alias of 'b' or 'a' is a
 copy of 'b'
 2. a = move(b); //now a is the only copy (the only alias ;))
 3. a = b.save(); //now a is guaranteed to be a shallow copy

 By copy here it's implied that range preserves iteration state. The
 underlying values may be changed elsewhere.

 There could be some argument to make 1 always do 3 and trim it to 2
 rules. But ehm, sorry, classes as ranges can't do that so we are stuck.

 If I had to choose I'd drop the current OOP support of D in favor of
 simplifying things (only half-joking) :)
-- Dmitry Olshansky
Mar 15 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 9:54 AM, deadalnix wrote:
 I have other benefit, as the capability for the compiler to give understandable
 error message instead of a wall of template errors.
Syntactic error messages would be the same in either case.
Mar 14 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 This is usualy much better to have the compiler smash your 
 mistake right
 into your face than discovering with a unittest much latter.
I don't think so.
Why?
 My argument is that adding an additional layer of typing on top 
 of templates caters to people who want to ship code that has 
 literally zero testing. That's not a priority as far as I'm 
 concerned.
If those people want yo write zero unit tests, they will write zero unit tests in both cases. I have seen D code like that. Introducing some compiler tests isn't going to make that situation worse and it's able to give better&nicer error messages when you have just written a template and you have not yet written a unittest (assuming you aren't using Test-Driven-Development). A template unittest often doesn't cover all possible instantiations of a template. So some compiler tests that work on all possible instantiations can help. You can also look at the situation from the other way: assuming you are correct, what currently present compiler tests do you want to remove? Bye, bearophile
Mar 14 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 1:07 PM, bearophile wrote:
 Andrei Alexandrescu:

 This is usualy much better to have the compiler smash your mistake right
 into your face than discovering with a unittest much latter.
I don't think so.
Why?
It's just an entirely different scenario. I can easily imagine a unittest failing to cover the entirety of possible flows in a function (particularly when exceptions get involved!). So clearly unittests define a spectrum of checking. In contrast, with typos in templates unittests are Boolean function. Either the thing compiles or it doesn't, no other way about it. Consider https://github.com/D-Programming-Language/phobos/pull/1205. I wrote unittests for the straight version and for pairwise summation, but not for Kahan. The code passed unittests, but clearly that wasn't enough. So I added the SList-based test to make sure the Kahan version works, and lo and behold I found typos in it that made it uncompilable, AND then run-time bugs that made it produce incorrect results. A concept system would have helped me there if my intent was to ship Kahan summation without ever testing it. That's not an intent we want to cater for!
 My argument is that adding an additional layer of typing on top of
 templates caters to people who want to ship code that has literally
 zero testing. That's not a priority as far as I'm concerned.
If those people want yo write zero unit tests, they will write zero unit tests in both cases. I have seen D code like that. Introducing some compiler tests isn't going to make that situation worse and it's able to give better&nicer error messages when you have just written a template and you have not yet written a unittest (assuming you aren't using Test-Driven-Development).
It has happened (very rarely) that pieces of generic code in Phobos had errors. I don't think those deserve help from the compiler. Andrei
Mar 14 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 A concept system would have helped me there if my intent was to 
 ship Kahan summation without ever testing it. That's not an 
 intent we want to cater for!
I think Issue 9715 isn't about Concepts. - - - - - Regarding the more general topic of Concepts (and their almost equivalent Typeclasses (http://dotat.at/tmp/p37-bernardy.pdf ) of the Rust language, or more powerful in Haskell), the argument you are proposing is exactly the same used by dynamic language proponents against static typing. A difference is that adding a static type system to Ruby causes much larger changes compared to adding typeclasses to Rust (Rust didn't have typeclasses since recently. Rust used to have templates similar to C++, with some restrictions). Haskell programmers have typeclasses, yet unit testing is done in Haskell, they have even invented a testing idea that was widely copied (QuickCheck). Types (like ones of Typeclasses and Concepts) help avoid catch some bugs and shape your style of coding, the unittests avoid the other bugs and shape your coding, and contract programming catches other bugs and they too shape the way you code, for the better. In the last Haskell version they have introduced a static type system at level of kinds, and it helps avoid some other bugs, or to catch them earlier. For a Haskell programmer the great and numerous advantages of Concepts/Typeclasses are not in discussion. I think Rust programmers are now learning to appreciate them. Bye, bearophile
Mar 14 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 12:48:28PM -0400, Andrei Alexandrescu wrote:
 On 3/14/13 11:50 AM, deadalnix wrote:
On Thursday, 14 March 2013 at 15:38:53 UTC, Andrei Alexandrescu wrote:
On 3/14/13 11:05 AM, monarch_dodra wrote:
Having to instantiate a template just to check to make sure it is
semantically correct is a huge pain.
I'm not sure about that. The way I see it, no code should be not delivered without being unittested. Ubiquitous unittesting is now mainstream. The way I see it, a type system on top of templates would only help people who don't write unittests.
[...]
I don't say that unittest are useless, but why rely on unittest when
the machine can do the job for you ?
In both cases the machine does the work. My argument is that adding an additional layer of typing on top of templates caters to people who want to ship code that has literally zero testing. That's not a priority as far as I'm concerned.
[...] I don't agree. Phobos is a prime example. Does Phobos have unittests? Yes, and lots of them. Does it still have non-compilable template instantiations? Yes, because unittests can't cover all possibilities -- there are too many possible combinations of template arguments. There are bound to be untested combinations which don't work but we're unaware of. We could, of course, automatically generate a very large number of template argument combinations and check to see if they're instantiable. In fact, we could write unittests that loop over every combination of a given list of types and instantiate the template to be tested with them. This is well within D's metaprogramming capabilities. But if we have to go that far, then it begs the original question: why not have the compiler do that for us? The compiler is better poised to make certain deductions using the type system, semantic analysis, etc., so that it doesn't literally have to enumerate every possible combination of template instantiation arguments just to prove it has no uncompilable instantiations. While I don't think D in its current state is going to be able to do this in a full way, the argument of catering to people shipping code without testing is invalid IMO. T -- Life would be easier if I had the source code. -- YHL
Mar 14 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 1:48 PM, H. S. Teoh wrote:
 I don't agree. Phobos is a prime example. Does Phobos have unittests?
 Yes, and lots of them. Does it still have non-compilable template
 instantiations? Yes, because unittests can't cover all possibilities --
 there are too many possible combinations of template arguments. There
 are bound to be untested combinations which don't work but we're unaware
 of.
If you found a few, that would be great. I don't think you'll have an easy time. Andrei
Mar 14 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 14 March 2013 at 17:51:23 UTC, Andrei Alexandrescu 
wrote:
 If you found a few, that would be great. I don't think you'll 
 have an easy time.

 Andrei
In other comment I have mentioned a case I have fixed just 15 days ago: https://github.com/D-Programming-Language/phobos/pull/1182 100% line coverage, compile-time error for certain type parameter subset. Could have been found by compiler / clever-enough framework. That was easy.
Mar 14 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 2:07 PM, Dicebot wrote:
 On Thursday, 14 March 2013 at 17:51:23 UTC, Andrei Alexandrescu wrote:
 If you found a few, that would be great. I don't think you'll have an
 easy time.

 Andrei
In other comment I have mentioned a case I have fixed just 15 days ago: https://github.com/D-Programming-Language/phobos/pull/1182 100% line coverage, compile-time error for certain type parameter subset. Could have been found by compiler / clever-enough framework. That was easy.
1 < a few Andrei
Mar 14 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 02:54:17PM -0400, Andrei Alexandrescu wrote:
 On 3/14/13 2:07 PM, Dicebot wrote:
On Thursday, 14 March 2013 at 17:51:23 UTC, Andrei Alexandrescu wrote:
If you found a few, that would be great. I don't think you'll have
an easy time.

Andrei
In other comment I have mentioned a case I have fixed just 15 days ago: https://github.com/D-Programming-Language/phobos/pull/1182 100% line coverage, compile-time error for certain type parameter subset. Could have been found by compiler / clever-enough framework. That was easy.
1 < a few
[...] I found (and fixed!) a number of missed combinations in std.algorithm: transient ranges, joiner() not using .save on forward ranges, same bug in transposed(), transposed crashing on jagged range of ranges, etc.. Given that some of this code is rather old before I touched them, I'm forced to believe that many more such bugs lurk in Phobos that nobody has found yet. Or they found it but just evaded it by rewriting some user code -- I've found myself doing that on several occasions, because I was trying to get my own code done and didn't want to spend another 4 hours' digression to find where the bug in Phobos is. Sometimes I don't even file bugs because it takes time to reduce the test case and it's distracting from the task at hand. So no, it's not just 1. They are there, and there are more than 1 of them, if you'd only look. I don't think denying this is helpful to improving Phobos' quality. T -- Without geometry, life would be pointless. -- VS
Mar 14 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 3:04 PM, H. S. Teoh wrote:
 I found (and fixed!) a number of missed combinations in std.algorithm:
 transient ranges, joiner() not using .save on forward ranges, same bug
 in transposed(), transposed crashing on jagged range of ranges, etc..
I think you're right but only in part; there may be a bit of a confusion. There's pure semantic checking such as forgetting to use .save that can't be detected statically. Then there's code that e.g. should work for forward ranges but has only been tested with arrays. My question was referring to code that has sheer typos that are mechanically detected, which are present in code that has never ever been instantiated. I do recall we found a few, but I think that illustrates a problem with the process, not the language. Andrei
Mar 14 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 14, 2013 15:18:56 Andrei Alexandrescu wrote:
 On 3/14/13 3:04 PM, H. S. Teoh wrote:
 I found (and fixed!) a number of missed combinations in std.algorithm:
 transient ranges, joiner() not using .save on forward ranges, same bug
 in transposed(), transposed crashing on jagged range of ranges, etc..
I think you're right but only in part; there may be a bit of a confusion. There's pure semantic checking such as forgetting to use .save that can't be detected statically. Then there's code that e.g. should work for forward ranges but has only been tested with arrays.
Those tend to be somewhat common, though we've been cutting down on them.
 My question was referring to code that has sheer typos that are
 mechanically detected, which are present in code that has never ever
 been instantiated. I do recall we found a few, but I think that
 illustrates a problem with the process, not the language.
Those tend to be _very_ rare. I wouldn't say that we've _never_ seen one In Phobos, but I sure don't remember one. And that's something that 100% code coverage catches easily. It's the semantic issues where it doesn't. - Jonathan M Davis
Mar 14 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 01:51:23PM -0400, Andrei Alexandrescu wrote:
 On 3/14/13 1:48 PM, H. S. Teoh wrote:
I don't agree. Phobos is a prime example. Does Phobos have unittests?
Yes, and lots of them. Does it still have non-compilable template
instantiations? Yes, because unittests can't cover all possibilities --
there are too many possible combinations of template arguments. There
are bound to be untested combinations which don't work but we're unaware
of.
If you found a few, that would be great. I don't think you'll have an easy time.
[...] It's easier than you think. I've stumbled across a few before. All you have to do is to start instantiating things with various combinations of const, immutable, class-based ranges instead of structs, etc., and all those little corner cases will start showing up. T -- Never wrestle a pig. You both get covered in mud, and the pig likes it.
Mar 14 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/14/2013 06:51 PM, Andrei Alexandrescu wrote:
 On 3/14/13 1:48 PM, H. S. Teoh wrote:
 I don't agree. Phobos is a prime example. Does Phobos have unittests?
 Yes, and lots of them. Does it still have non-compilable template
 instantiations? Yes, because unittests can't cover all possibilities --
 there are too many possible combinations of template arguments. There
 are bound to be untested combinations which don't work but we're unaware
 of.
If you found a few, that would be great. I don't think you'll have an easy time. Andrei
Challenge accepted. Clearly the Phobos developers do not instantiate their templates before shipping them. :o) The following breaks most of std.range, and most of std.algorithm could likely be broken too, but I am too lazy to investigate. import std.range, std.algorithm; struct TrollFace{ property string front()const{ return "troll"; } property string back()const{ return "face"; } property bool empty()const{ return true; } void popFront()const{ } void popBack()const{ } property inout(TrollFace) save()inout{ return this; } auto opIndex(size_t index){ return front; } property size_t length()inout{ return 0; } int* x; } struct TrollierFace{ TrollFace face; alias face this; disable this(this); property inout(TrollierFace) save()inout{ return inout(TrollierFace)(face); } } void main(){ immutable TrollFace a,b,c; a.retro(); a.stride(2); chain(a,b,c); roundRobin(a,b,c); a.radial(); a.radial(0); a.take(2); (immutable(TrollierFace)()).takeExactly(2); (immutable(TrollierFace)()).takeOne(); (immutable(TrollierFace)()).takeNone(); (immutable(TrollierFace)()).drop(2); (immutable(TrollierFace)()).dropExactly(0); (immutable(TrollierFace)()).dropOne(); (immutable(TrollierFace)()).repeat(); a.cycle(); a.zip(b); lockstep((immutable(TrollierFace)()),b); a.frontTransversal(); a.transversal(0); a.indexed([0]); a.chunks(5); a.filter!(a=>true); a.map!(a=>a); // ... (and so on) }
Mar 14 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
You are awesome.
Mar 14 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 1:57 PM, Timon Gehr wrote:
 The following breaks most of std.range, and most of std.algorithm could likely
 be broken too, but I am too lazy to investigate.
Please file this with bugzilla.
Mar 14 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 02:37:29PM -0700, Walter Bright wrote:
 On 3/14/2013 1:57 PM, Timon Gehr wrote:
The following breaks most of std.range, and most of std.algorithm could likely
be broken too, but I am too lazy to investigate.
Please file this with bugzilla.
I think it deserves several different bug reports, as they appear to be failing in different places. T -- Always remember that you are unique. Just like everybody else. -- despair.com
Mar 14 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/14/2013 10:37 PM, Walter Bright wrote:
 On 3/14/2013 1:57 PM, Timon Gehr wrote:
 The following breaks most of std.range, and most of std.algorithm
 could likely
 be broken too, but I am too lazy to investigate.
Please file this with bugzilla.
http://d.puremagic.com/issues/show_bug.cgi?id=9724
Mar 14 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 4:57 PM, Timon Gehr wrote:
 On 03/14/2013 06:51 PM, Andrei Alexandrescu wrote:
 On 3/14/13 1:48 PM, H. S. Teoh wrote:
 I don't agree. Phobos is a prime example. Does Phobos have unittests?
 Yes, and lots of them. Does it still have non-compilable template
 instantiations? Yes, because unittests can't cover all possibilities --
 there are too many possible combinations of template arguments. There
 are bound to be untested combinations which don't work but we're unaware
 of.
If you found a few, that would be great. I don't think you'll have an easy time. Andrei
Challenge accepted. Clearly the Phobos developers do not instantiate their templates before shipping them. :o) The following breaks most of std.range, and most of std.algorithm could likely be broken too, but I am too lazy to investigate.
[snip] Nice point. The problem is an immutable TrollFace should not qualify pass the range tests. This could happen if there was a similar bug in a concept definition. So your argument does not move the ball on concepts vs static if. Andrei
Mar 14 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/14/2013 10:48 PM, Andrei Alexandrescu wrote:
 On 3/14/13 4:57 PM, Timon Gehr wrote:
 ...

 The following breaks most of std.range, and most of std.algorithm could
 likely be broken too, but I am too lazy to investigate.
[snip] Nice point. The problem is an immutable TrollFace should not qualify pass the range tests.
Yes, that is one valid analysis of the situation.
 This could happen if there was a similar bug in a
 concept definition.
Yes. In which case it would be detected while the code is written, which is the point.
 So your argument does not move the ball on concepts
 vs static if.
...
I'm not intending to move any balls here. The trade-offs are different.
Mar 14 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 1:57 PM, Timon Gehr wrote:
 Challenge accepted. Clearly the Phobos developers do not instantiate their
 templates before shipping them. :o)

 The following breaks most of std.range, and most of std.algorithm could likely
 be broken too, but I am too lazy to investigate.
Compiling with -cov -unittest shows: std.range 86% covered "good" std.algorithm 96% covered "excellent"
Mar 14 2013
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 14 March 2013 at 20:57:57 UTC, Timon Gehr wrote:
 On 03/14/2013 06:51 PM, Andrei Alexandrescu wrote:
 On 3/14/13 1:48 PM, H. S. Teoh wrote:
 I don't agree. Phobos is a prime example. Does Phobos have 
 unittests?
 Yes, and lots of them. Does it still have non-compilable 
 template
 instantiations? Yes, because unittests can't cover all 
 possibilities --
 there are too many possible combinations of template 
 arguments. There
 are bound to be untested combinations which don't work but 
 we're unaware
 of.
If you found a few, that would be great. I don't think you'll have an easy time. Andrei
Challenge accepted. Clearly the Phobos developers do not instantiate their templates before shipping them. :o) The following breaks most of std.range, and most of std.algorithm could likely be broken too, but I am too lazy to investigate.
All this breakage is just one and the same bug. These ranges, for some reason, are testing Unqual!Range, and then attempt to store an Unqual!Range, which makes no sense, since the passed type is not Unqual!Range, it's Range. Probably an old C++ habit, where you can cast away constness by copy. This is not the case in D. In any case, all of std.range (and some of algorithm) need to be stripped of this.
Mar 14 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/15/2013 12:18 AM, monarch_dodra wrote:
 On Thursday, 14 March 2013 at 20:57:57 UTC, Timon Gehr wrote:
 ...

 Challenge accepted. Clearly the Phobos developers do not instantiate
 their templates before shipping them. :o)

 The following breaks most of std.range, and most of std.algorithm
 could likely be broken too, but I am too lazy to investigate.
All this breakage is just one and the same bug. ...
Even if you count all bugs of the same kind as one bug, there are at least two.
Mar 15 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/14/2013 06:48 PM, H. S. Teoh wrote:
 ...

 We could, of course, automatically generate a very large number of
 template argument combinations and check to see if they're instantiable.
 In fact, we could write unittests that loop over every combination of a
 given list of types and instantiate the template to be tested with them.
 This is well within D's metaprogramming capabilities.

 ...
But way behind state-of-the-art research in program validation.
Mar 14 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 08:49:11PM +0100, Timon Gehr wrote:
 On 03/14/2013 06:48 PM, H. S. Teoh wrote:
...

We could, of course, automatically generate a very large number of
template argument combinations and check to see if they're
instantiable.  In fact, we could write unittests that loop over every
combination of a given list of types and instantiate the template to
be tested with them.  This is well within D's metaprogramming
capabilities.

...
But way behind state-of-the-art research in program validation.
Yes, which was my point. T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Mar 14 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/14/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 But if we have to go that far, then it begs the original question: why
 not have the compiler do that for us?
But where do you draw the line? There could be an unlimited number of permutations of how a template is instantiated. This would blow up compilation time by an unknown factor. And I doubt this would be simple to implement too.
Mar 14 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 06:56:56PM +0100, Andrej Mitrovic wrote:
 On 3/14/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 But if we have to go that far, then it begs the original question:
 why not have the compiler do that for us?
But where do you draw the line? There could be an unlimited number of permutations of how a template is instantiated. This would blow up compilation time by an unknown factor. And I doubt this would be simple to implement too.
But that was my point, if we had concepts, then the compiler could statically check the syntax of the template without needing to iterate over all combinations of types. Right now, we *have* to essentially check all combinations in unittests if we want to be sure that the template is instantiable in all cases. T -- Your inconsistency is the only consistent thing about you! -- KD
Mar 14 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 11:04 AM, H. S. Teoh wrote:
 But that was my point, if we had concepts, then the compiler could
 statically check the syntax of the template without needing to iterate
 over all combinations of types.
A syntax check is not a semantic check.
 Right now, we *have* to essentially check all combinations in unittests
 if we want to be sure that the template is instantiable in all cases.
You have to anyway. Consider functions. Just because the function passes syntactical and semantic checks does not at all mean it passes with all combinations of parameter values. We still need unittests, and while unittests also do not guarantee the function is correct in all cases, it is considered unprofessional to ship a function that was never called at runtime in any tests.
Mar 14 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 8:50 AM, deadalnix wrote:
 This is usualy much better to have the compiler smash your mistake right into
 your face than discovering with a unittest much latter.
I wish to point out that semantic checking would not be done at compile time, only syntax checking.
Mar 14 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I'm not sure about that. The way I see it, no code should be 
 not delivered without being unittested. Ubiquitous unittesting 
 is now mainstream. The way I see it, a type system on top of 
 templates would only help people who don't write unittests.
This is an invalid argument. You can say the same thing for many (most?) tests done by the compiler. Unit tests can't be sure to verify all code paths inside a function or template. But the tests done by the compiler discussed here are like a type system, that verifies all (or most) code paths at once. Bye, bearophile
Mar 14 2013
next sibling parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
 From 
http://herbsutter.com/2013/03/14/words-of-wisdom-bjarne-stroustrup/?utm_source=tf&utm_medium=t

Bjarne Stroustrup wrote the following a few minutes ago on the 
concepts mailing list:

"Let me take this opportunity to remind people that

* "being able to do something is not sufficient reason for doing 
it" and
* "being able to do every trick is not a feature but a bug"

For the latter, remember Dijkstra’s famous "Goto considered 
harmful" paper. The point was not that the "new features" (loop 
constructs) could do every goto trick better/simpler, but that 
some of those tricks should be avoided to simplify good 
programming.

Concepts and concepts lite are meant to make good generic 
programming simpler. They are not meant to be a drop-in 
substitute for every metaprogramming and macroprogramming trick. 
If you are an expert, and if in your expert opinion you and your 
users really need those tricks, you can still use them, but we 
need to make many (most) uses of templates easier to get right, 
so that they can become more mainstream. That where concepts and 
concept lite fits in.

Some of you may find this hard to believe, but "back then" there 
was quite serious opposition to function declarations because 
"they restricted the way functions could be used and the way 
separate compilation could be used" and also serious opposition 
to virtual functions "because pointers to functions are so much 
more flexible." I see concepts lite (and concepts) in the same 
light as goto/for, 
unchecked-function-arguments/function-declarations, 
pointers-to-functions/abstract-classes."
Mar 14 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 12:32 PM, bearophile wrote:
 Andrei Alexandrescu:

 I'm not sure about that. The way I see it, no code should be not
 delivered without being unittested. Ubiquitous unittesting is now
 mainstream. The way I see it, a type system on top of templates would
 only help people who don't write unittests.
This is an invalid argument. You can say the same thing for many (most?) tests done by the compiler.
No, this is different. Andrei
Mar 14 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 No, this is different.
Why? Bye, bearophile
Mar 14 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 14 Mar 2013 12:48:28 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 On 3/14/13 11:50 AM, deadalnix wrote:
 This is usualy much better to have the compiler smash your mistake
 right into your face than discovering with a unittest much latter.
I don't think so.
On Thu, 14 Mar 2013 12:49:01 -0400 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 On 3/14/13 12:32 PM, bearophile wrote:
 This is an invalid argument. You can say the same thing for many
 (most?) tests done by the compiler.
No, this is different.
Man: An argument is a connected series of statements intended to establish a proposition. Andrei: No it isn't. Man: Yes it is! It's not just contradiction. Andrei: Look, if I argue with you, I must take up a contrary position. Man: Yes, but that's not just saying 'No it isn't.' Andrei: Yes it is! Man: No it isn't! Andrei: Yes it is! Man: Argument is an intellectual process. Contradiction is just the automatic gainsaying of any statement the other person makes. (short pause) Andrei: No it isn't.
Mar 14 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 1:58 PM, Nick Sabalausky wrote:
 On Thu, 14 Mar 2013 12:48:28 -0400
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:
 On 3/14/13 11:50 AM, deadalnix wrote:
 This is usualy much better to have the compiler smash your mistake
 right into your face than discovering with a unittest much latter.
I don't think so.
On Thu, 14 Mar 2013 12:49:01 -0400 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 On 3/14/13 12:32 PM, bearophile wrote:
 This is an invalid argument. You can say the same thing for many
 (most?) tests done by the compiler.
No, this is different.
Man: An argument is a connected series of statements intended to establish a proposition. Andrei: No it isn't. Man: Yes it is! It's not just contradiction. Andrei: Look, if I argue with you, I must take up a contrary position. Man: Yes, but that's not just saying 'No it isn't.' Andrei: Yes it is! Man: No it isn't! Andrei: Yes it is! Man: Argument is an intellectual process. Contradiction is just the automatic gainsaying of any statement the other person makes. (short pause) Andrei: No it isn't.
No. Andrei
Mar 14 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/14/13, bearophile <bearophileHUGS lycos.com> wrote:
 This is an invalid argument. You can say the same thing for many
 (most?) tests done by the compiler. Unit tests can't be sure to
 verify all code paths inside a function or template.
No, it must do exactly that. If you have so many paths that you can't reasonably test all paths then your template or function is too complicated to begin with. The benefit here of D over C++ is that unit testing is cheap and doesn't require external libraries. You use template constraints to limit the code paths, and you use unittests to verify semantics. Then there's also static assert(0).
Mar 14 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 14 March 2013 at 17:09:41 UTC, Andrej Mitrovic wrote:
 On 3/14/13, bearophile <bearophileHUGS lycos.com> wrote:
 This is an invalid argument. You can say the same thing for 
 many
 (most?) tests done by the compiler. Unit tests can't be sure to
 verify all code paths inside a function or template.
No, it must do exactly that. If you have so many paths that you can't reasonably test all paths then your template or function is too complicated to begin with. The benefit here of D over C++ is that unit testing is cheap and doesn't require external libraries. You use template constraints to limit the code paths, and you use unittests to verify semantics. Then there's also static assert(0).
Does Phobos pull request tester turns red on failed 100% coverage? (sarcasm intended)
Mar 14 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 1:15 PM, Dicebot wrote:
 On Thursday, 14 March 2013 at 17:09:41 UTC, Andrej Mitrovic wrote:
 On 3/14/13, bearophile <bearophileHUGS lycos.com> wrote:
 This is an invalid argument. You can say the same thing for many
 (most?) tests done by the compiler. Unit tests can't be sure to
 verify all code paths inside a function or template.
No, it must do exactly that. If you have so many paths that you can't reasonably test all paths then your template or function is too complicated to begin with. The benefit here of D over C++ is that unit testing is cheap and doesn't require external libraries. You use template constraints to limit the code paths, and you use unittests to verify semantics. Then there's also static assert(0).
Does Phobos pull request tester turns red on failed 100% coverage? (sarcasm intended)
Walter has measured coverage of Phobos unittests a couple of times, it's very high. But I agree it would be nice to have it as a target. Andrei
Mar 14 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 14 March 2013 at 17:26:18 UTC, Andrei Alexandrescu 
wrote:
 Walter has measured coverage of Phobos unittests a couple of 
 times, it's very high. But I agree it would be nice to have it 
 as a target.

 Andrei
Sarcasm aside, this brought me to an idea for utilities for template fuzzy testing to check some instantiation combinations. Which is much more useful than plain line coverage check in case of templates. I have submitted pull request only a few weeks ago that fixed std.traits bug where template has failed to instantiate for function types (but not other types) despite 100% line coverage by unit test. It could have been checked automagically. Not sure what usage interface may be though.
Mar 14 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 07:00:47PM +0100, Dicebot wrote:
 On Thursday, 14 March 2013 at 17:26:18 UTC, Andrei Alexandrescu
 wrote:
Walter has measured coverage of Phobos unittests a couple of times,
it's very high. But I agree it would be nice to have it as a target.

Andrei
Beware the fallacy that 100% line coverage of a template == 100% coverage of correctness in *every possible instantiation*. Just because template X has 100% line coverage for !(int,int) does not necessarily mean it will work for !(int,string), for example. Or !(int,const(int)). Or !(const(int),int). Or any number of subtle but sometimes important combinations.
 Sarcasm aside, this brought me to an idea for utilities for template
 fuzzy testing  to check some instantiation combinations. Which is much
 more useful than plain line coverage check in case of templates. I
 have submitted pull request only a few weeks ago that fixed std.traits
 bug where template has failed to instantiate for function types (but
 not other types) despite 100% line coverage by unit test. It could
 have been checked automagically.
 
 Not sure what usage interface may be though.
I've written code like this before, though it definitely can use some refinement: struct MySet(ElemType) { ... } unittest { void test(T)(T sampleArgs) { auto set = MySet!T(sampleArgs); assert( ... /* test for MySet behaviour here */); } void testNumArray(T, U...)() { T[] data = [1,2,3,4,5]; test(data); testNumArray!(U); } void testCharArray(T, U...)() { T[] data = "abc"; test(data); testCharArray!(U); } testNumArray!(byte, ubyte, int, uint, long, ulong)(); testCharArray!(char, wchar, dchar, const(char), const(wchar), const(dchar), immutable(char), immutable(wchar), immutable(dchar))(); // Coverage is still not really complete; we'd need to // add struct and class, and nested arrays, etc.. } The fact that D actually lets you do this, is quite awesome. T -- He who laughs last thinks slowest.
Mar 14 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 14, 2013 13:26:18 Andrei Alexandrescu wrote:
 Walter has measured coverage of Phobos unittests a couple of times, it's
 very high. But I agree it would be nice to have it as a target.
Though this is exactly a case where 100% unit test coverage doesn't mean much. All that means is that each path has been instantiated and run. It doesn't mean that it's covered enough possible instantiations to properly test the template. For instance, a simple bug like making it so that hasLength!R ends up choosing a static if path which assumes random access wouldn't be caught unless you happened to test that template with a range which has length but doesn't have random access, and even with thorough testing, there's bound to be some particular genre of range that gets missed in the unit tests. But barring something that makes it impossible or unreasonable, we really should be shooting for 100% code coverage. assert(0) would a prime case where it's impossible (even std.datetime only had 98% or 99% code coverage the last time I checked, precisely because of assert(0)), and I'm sure that there are other cases, but we should be able to get close. - Jonathan M Davis
Mar 14 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 11:38 AM, Jonathan M Davis wrote:
 Though this is exactly a case where 100% unit test coverage doesn't mean much.
 All that means is that each path has been instantiated and run. It doesn't
 mean that it's covered enough possible instantiations to properly test the
 template.
I understand this. But my experience in the matter has been that if the tests cover 100% of the code paths, the incidence of undetected bugs in the code goes very, very low. So, I disagree with "doesn't mean much". Pedantically, it means little, but practically, it means a great deal. (Of course, for multithreading you'd be right - runtime testing is notoriously unproductive in finding concurrency mistakes.)
Mar 14 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I understand this. But my experience in the matter has been 
 that if the tests cover 100% of the code paths, the incidence 
 of undetected bugs in the code goes very, very low.
This is not so much true for template-heavy code. And 100% code coverage is not enough even for regular code, that's why they have invented this for Java: http://dev.theladders.com/2013/02/mutation-testing-with-pit-a-step-beyond-normal-code-coverage/ Bye, bearophile
Mar 14 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 2:26 PM, bearophile wrote:
 Walter Bright:

 I understand this. But my experience in the matter has been that if the tests
 cover 100% of the code paths, the incidence of undetected bugs in the code
 goes very, very low.
This is not so much true for template-heavy code.
I don't believe that without further evidence.
 And 100% code coverage is not enough even for regular code,
I didn't say it was perfect. I said it is very effective, and doesn't leave much left. I have very positive experience with code I took the time to do coverage testing on, and so have others.
Mar 14 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 14, 2013 14:40:11 Walter Bright wrote:
 On 3/14/2013 2:26 PM, bearophile wrote:
 Walter Bright:
 I understand this. But my experience in the matter has been that if the
 tests cover 100% of the code paths, the incidence of undetected bugs in
 the code goes very, very low.
This is not so much true for template-heavy code.
I don't believe that without further evidence.
It's been fairly frequent that std.range and std.algorithm don't work correctly with reference type ranges. The only way to catch that is to test those functions with reference type ranges. 100% code coverage won't get you there. I fully agree that it's a big step in the right direction, but I don't think that it's been all that uncommon for there to be bugs in Phobos where some ranges work and some don't when the buggy function had high code coverage - it just was likely to be testing primarily with arrays and not enough with other range types. We've definitely been reducing the number of those types of bugs, but they were caught because people tried to instantiate them with types that the unit tests didn't test. - Jonathan M Davis
Mar 14 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 10:26:54PM +0100, bearophile wrote:
[[...]
 And 100% code coverage is not enough even for regular code, that's why
 they have invented this for Java:
 
 http://dev.theladders.com/2013/02/mutation-testing-with-pit-a-step-beyond-normal-code-coverage/
[...] We need this in D. I want this in D. :) Recently, while writing a new D module, the thought occurred to me that perhaps my unittests aren't enough. Sure, it's good to have tons of unittests, but how effective are they? Do they really fail when I think they should, or do they just silently pass anyway when a bug is introduced? This paper answered that question for me. :) I think maybe the dustmite code can be adapted to do mutation testing, esp. the part that identifies what can be deleted from the code? I'm not sure exactly how dustmite identifies declarations/statements to be deleted, but that could be a start on doing mutation testing. T -- Why can't you just be a nonconformist like everyone else? -- YHL
Mar 14 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 2:38 PM, Jonathan M Davis wrote:
 On Thursday, March 14, 2013 13:26:18 Andrei Alexandrescu wrote:
 Walter has measured coverage of Phobos unittests a couple of times, it's
 very high. But I agree it would be nice to have it as a target.
Though this is exactly a case where 100% unit test coverage doesn't mean much. All that means is that each path has been instantiated and run. It doesn't mean that it's covered enough possible instantiations to properly test the template.
Concepts won't help there either. Andrei
Mar 14 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 05:54:05PM -0400, Andrei Alexandrescu wrote:
 On 3/14/13 2:38 PM, Jonathan M Davis wrote:
On Thursday, March 14, 2013 13:26:18 Andrei Alexandrescu wrote:
Walter has measured coverage of Phobos unittests a couple of times,
it's very high. But I agree it would be nice to have it as a target.
Though this is exactly a case where 100% unit test coverage doesn't mean much. All that means is that each path has been instantiated and run. It doesn't mean that it's covered enough possible instantiations to properly test the template.
Concepts won't help there either.
[...] It does help. For example, if the code wrongly assumes mutability for a particular template type, then it may work for most test cases (frankly, I find const/immutable unittest coverage in Phobos very poor) but fail when some daring user passes const(T) instead of T to the template. For example, you may have accidentally written the equivalent of: auto func(T)(T t) { Unqual!T u = t; // <-- spot the bug ... } Under a concepts system, this would be caught early because the compiler would detect a concept mismatch (Unqual!T != T) when analysing the template code. Currently, though, if there is no unittest that tries instantiating the template with const(T), the bug goes undetected, because in all *tested* instantiations, Unqual!T == T. T -- Famous last words: I wonder what will happen if I do *this*...
Mar 14 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 3:02 PM, H. S. Teoh wrote:
 Under a concepts system, this would be caught early because the compiler
 would detect a concept mismatch (Unqual!T != T) when analysing the
 template code.
How would that be different from simply adding a template constraint?
Mar 14 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 6:15 PM, Walter Bright wrote:
 On 3/14/2013 3:02 PM, H. S. Teoh wrote:
 Under a concepts system, this would be caught early because the compiler
 would detect a concept mismatch (Unqual!T != T) when analysing the
 template code.
How would that be different from simply adding a template constraint?
The difference is without the constraint there's no error. It's all about the default: by default (no constraints) everything is allowed. Andrei
Mar 14 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 3:20 PM, Andrei Alexandrescu wrote:
 On 3/14/13 6:15 PM, Walter Bright wrote:
 On 3/14/2013 3:02 PM, H. S. Teoh wrote:
 Under a concepts system, this would be caught early because the compiler
 would detect a concept mismatch (Unqual!T != T) when analysing the
 template code.
How would that be different from simply adding a template constraint?
The difference is without the constraint there's no error. It's all about the default: by default (no constraints) everything is allowed.
I meant how would a concept be better than a constraint for this example.
Mar 14 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/13 6:02 PM, H. S. Teoh wrote:
 On Thu, Mar 14, 2013 at 05:54:05PM -0400, Andrei Alexandrescu wrote:
 On 3/14/13 2:38 PM, Jonathan M Davis wrote:
 On Thursday, March 14, 2013 13:26:18 Andrei Alexandrescu wrote:
 Walter has measured coverage of Phobos unittests a couple of times,
 it's very high. But I agree it would be nice to have it as a target.
Though this is exactly a case where 100% unit test coverage doesn't mean much. All that means is that each path has been instantiated and run. It doesn't mean that it's covered enough possible instantiations to properly test the template.
Concepts won't help there either.
[...] It does help. For example, if the code wrongly assumes mutability for a particular template type, then it may work for most test cases (frankly, I find const/immutable unittest coverage in Phobos very poor) but fail when some daring user passes const(T) instead of T to the template. For example, you may have accidentally written the equivalent of: auto func(T)(T t) { Unqual!T u = t; //<-- spot the bug ... } Under a concepts system, this would be caught early because the compiler would detect a concept mismatch (Unqual!T != T) when analysing the template code. Currently, though, if there is no unittest that tries instantiating the template with const(T), the bug goes undetected, because in all *tested* instantiations, Unqual!T == T.
Template constraints start from the most permissive end of the spectrum: by default there's no verification, and constraints add verification. With typeclasses it's the other way around: by default nothing is allowed, so code needs to add permissions explicitly. I agree that in that regard typeclasses are better than template constraints. Of course there are many other aspects to be considered when comparing the two. Andrei
Mar 14 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 06:18:58PM -0400, Andrei Alexandrescu wrote:
 On 3/14/13 6:02 PM, H. S. Teoh wrote:
On Thu, Mar 14, 2013 at 05:54:05PM -0400, Andrei Alexandrescu wrote:
On 3/14/13 2:38 PM, Jonathan M Davis wrote:
[...]
Though this is exactly a case where 100% unit test coverage doesn't
mean much.  All that means is that each path has been instantiated
and run. It doesn't mean that it's covered enough possible
instantiations to properly test the template.
Concepts won't help there either.
[...] It does help. For example, if the code wrongly assumes mutability for a particular template type, then it may work for most test cases (frankly, I find const/immutable unittest coverage in Phobos very poor) but fail when some daring user passes const(T) instead of T to the template. For example, you may have accidentally written the equivalent of: auto func(T)(T t) { Unqual!T u = t; //<-- spot the bug ... } Under a concepts system, this would be caught early because the compiler would detect a concept mismatch (Unqual!T != T) when analysing the template code. Currently, though, if there is no unittest that tries instantiating the template with const(T), the bug goes undetected, because in all *tested* instantiations, Unqual!T == T.
Template constraints start from the most permissive end of the spectrum: by default there's no verification, and constraints add verification. With typeclasses it's the other way around: by default nothing is allowed, so code needs to add permissions explicitly.
I like this way of looking at it. So basically, typeclasses force us to state all assumptions up-front, whereas template constraints leave room for oversight (forget to put isForwardRange!R in the constraints but use .save in the function body).
 I agree that in that regard typeclasses are better than template
 constraints. Of course there are many other aspects to be considered
 when comparing the two.
[...] Yes, and I'm not saying that we should discard template constraints and adopt typeclasses wholesale. I can't say I'm totally sold on typeclasses either, because they do introduce their own tradeoffs. But neither should we dismiss the typeclasses approach so lightly. In fact, now that I think of it, templates in general suffer from this problem: when you write template X(T) { ... }, pretty much anything goes in the template body, even outright ridiculous things that won't compile for *any* template arguments. But more commonly, the template body may assume things about T that don't apply across all types T. You may assume that T is mutable, or that T has a certain member, etc.. What if templates were modified so that assumptions about T have to be stated up front? We don't necessarily have to introduce typeclasses as a separate thing, but we could have the compiler reject template bodies that try to access internals of T that aren't stated up front. E.g.: auto myFunc(T)(T t) { return t.fun(); // error: T wasn't stated to have a member named .fun } would produce a compile error, whereas: auto myFunc(T)(T t) if (hasMember!(T, "fun")) { return t.fun(); // OK: we stated that we expect T to have a .fun member } would be accepted. The stated assumptions can themselves be templates too, which are expanded by the compiler before checking the template body. (Presumably, hasMember will eventually expand to some compiler intrinsic that tells the compiler what assumptions are being made about T.) So we can still continue using things like isInputRange!T, etc., except that now the compiler will catch unstated assumptions. IOW, make signature constraints mandatory rather than optional. Arguably, signature constraints *should* be mandatory in properly-written generic code anyway, so this can only add value. And it will not break existing code if said code is properly-written. T -- The right half of the brain controls the left half of the body. This means that only left-handed people are in their right mind. -- Manoj Srivastava
Mar 14 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 What if templates were modified so that assumptions about T 
 have to be
 stated up front? We don't necessarily have to introduce 
 typeclasses as a
 separate thing, but we could have the compiler reject template 
 bodies
 that try to access internals of T that aren't stated up front. 
 E.g.:

 	auto myFunc(T)(T t) {
 		return t.fun();	// error: T wasn't stated to have a member 
 named .fun
 	}

 would produce a compile error, whereas:

 	auto myFunc(T)(T t)
 		if (hasMember!(T, "fun"))
 	{
 		return t.fun();	// OK: we stated that we expect T to have a 
 .fun member
 	}

 would be accepted. The stated assumptions can themselves be 
 templates
 too, which are expanded by the compiler before checking the 
 template
 body. (Presumably, hasMember will eventually expand to some 
 compiler
 intrinsic that tells the compiler what assumptions are being 
 made about
 T.) So we can still continue using things like isInputRange!T, 
 etc.,
 except that now the compiler will catch unstated assumptions.
What's the difference between this and Concepts (lite)? :-) Bye, bearophile
Mar 14 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 14 Mar 2013 15:57:59 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 
 In fact, now that I think of it, templates in general suffer from this
 problem: when you write template X(T) { ... }, pretty much anything
 goes in the template body, even outright ridiculous things that won't
 compile for *any* template arguments. But more commonly, the template
 body may assume things about T that don't apply across all types T.
 You may assume that T is mutable, or that T has a certain member,
 etc..
 
 What if templates were modified so that assumptions about T have to be
 stated up front? We don't necessarily have to introduce typeclasses
 as a separate thing, but we could have the compiler reject template
 bodies that try to access internals of T that aren't stated up front.
 E.g.:
 
that MS never bothered to provide a constraint for "can do arithmetic" (like they have for "can be compared", ie IComparable) so you can't do a basic thing like "a + b" generically.
Mar 14 2013
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 14, 2013 17:54:05 Andrei Alexandrescu wrote:
 On 3/14/13 2:38 PM, Jonathan M Davis wrote:
 On Thursday, March 14, 2013 13:26:18 Andrei Alexandrescu wrote:
 Walter has measured coverage of Phobos unittests a couple of times, it's
 very high. But I agree it would be nice to have it as a target.
Though this is exactly a case where 100% unit test coverage doesn't mean much. All that means is that each path has been instantiated and run. It doesn't mean that it's covered enough possible instantiations to properly test the template.
Concepts won't help there either.
Oh, they may not. My point was simply that while 100% code coverage is great, when you're dealing with templated functions, it's generally nowhere near enough (especially as the number of static ifs goes up), because there could easily be other template arguments which pass the template constraint but won't even compile with the template, let alone work correctly. For instance, while we've been getting better at it, it's generally been a weakness of std.range and std.algorithm that reference-type ranges aren't tested properly and don't work properly with various functions, and yet those same functions generally have good code coverage. Really, it just means that we need to be thorough in the number of template instantiations tested and not think that 100% code coverage is enough, but I can understand people wanting to find ways to get the compiler to catch some of that for them. - Jonathan M Davis
Mar 14 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 06:09:26PM +0100, Andrej Mitrovic wrote:
 On 3/14/13, bearophile <bearophileHUGS lycos.com> wrote:
 This is an invalid argument. You can say the same thing for many
 (most?) tests done by the compiler. Unit tests can't be sure to
 verify all code paths inside a function or template.
No, it must do exactly that. If you have so many paths that you can't reasonably test all paths then your template or function is too complicated to begin with. The benefit here of D over C++ is that unit testing is cheap and doesn't require external libraries.
[...] I think you're missing the point. The point is that concepts allow the compiler to deduce template correctness *without* instantiating it with every possible combination of types. Right now, we *don't* have concepts, and therefore the only way to ensure template correctness is to iterate over the exponential number of combinations of template arguments. But if we *had* concepts, then the compiler could reason about code correctness without needing to explicitly check every instantiation -- thus effectively covering all possible combinations, but without actually doing it. It's the difference between proving a boolean statement is tautologous by reducing it to true using known logic identities, vs. looping over every combination of variable assignments and checking that they all evaluate to true. T -- Кто везде - тот нигде.
Mar 14 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
14-Mar-2013 22:13, H. S. Teoh пишет:
 On Thu, Mar 14, 2013 at 06:09:26PM +0100, Andrej Mitrovic wrote:
 On 3/14/13, bearophile <bearophileHUGS lycos.com> wrote:
 This is an invalid argument. You can say the same thing for many
 (most?) tests done by the compiler. Unit tests can't be sure to
 verify all code paths inside a function or template.
No, it must do exactly that. If you have so many paths that you can't reasonably test all paths then your template or function is too complicated to begin with. The benefit here of D over C++ is that unit testing is cheap and doesn't require external libraries.
[...] I think you're missing the point. The point is that concepts allow the compiler to deduce template correctness *without* instantiating it with every possible combination of types. Right now, we *don't* have concepts, and therefore the only way to ensure template correctness is to iterate over the exponential number of combinations of template arguments.
And if you create a library tool to try out all sensible combinations would that work for this use case of concepts? In essence you transform concept to some specification and feed it into a CTFE-able generatopr function. Then take the code out and apply mixin it put into a unittest. Sounds easy (if only DMD doesn't run out of memory in the process). -- Dmitry Olshansky
Mar 14 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 14, 2013 at 10:20:04PM +0400, Dmitry Olshansky wrote:
 14-Mar-2013 22:13, H. S. Teoh пишет:
On Thu, Mar 14, 2013 at 06:09:26PM +0100, Andrej Mitrovic wrote:
On 3/14/13, bearophile <bearophileHUGS lycos.com> wrote:
This is an invalid argument. You can say the same thing for many
(most?) tests done by the compiler. Unit tests can't be sure to
verify all code paths inside a function or template.
No, it must do exactly that. If you have so many paths that you can't reasonably test all paths then your template or function is too complicated to begin with. The benefit here of D over C++ is that unit testing is cheap and doesn't require external libraries.
[...] I think you're missing the point. The point is that concepts allow the compiler to deduce template correctness *without* instantiating it with every possible combination of types. Right now, we *don't* have concepts, and therefore the only way to ensure template correctness is to iterate over the exponential number of combinations of template arguments.
And if you create a library tool to try out all sensible combinations would that work for this use case of concepts? In essence you transform concept to some specification and feed it into a CTFE-able generatopr function. Then take the code out and apply mixin it put into a unittest. Sounds easy (if only DMD doesn't run out of memory in the process).
[...] It's certainly possible, I think. Is it worth pursuing? Maybe. Here's a first crack at it: We'd need some way of listing (or generating a list of) all representative template arguments, say for example, a listing that includes input range, forward range, bidirectional range, etc.. Then we need a way to generically generate non-trivial instances of these ranges (otherwise the unittest could only cover trivial instances, like empty input range, empty forward range, etc., so the template being tested will not be verified for non-empty ranges!). The result then will be used to instantiate the template and run it through a battery of tests. Of course, the ranges themselves have arguments, so you'd need some kind of listing of representative types: char, int, float, string, etc., and have a way of generating non-trivial instances of each of these types, then use them to instantiate the range with. Maybe for each type also test it for const(T), immutable(T), etc.. Then you'd have to cover nested ranges, so you'd need a way to specify how deep you want to go (e.g., a recent forward range bug of using = instead of .save will only manifest itself if you had a nested range of forward ranges -- you couldn't catch that just by running through non-nested ranges). As you can see, this quickly explodes in exponential number of combinations. So ultimately, maybe we still have to resort to hand-picked "representative" types. But we can do better than the current ad-hoc scheme of writing unittests for whatever combination just occurred to the code writer (which usually misses a lot of corner cases). We should have a std.unittest module that contains lists of all numeric types (byte, int, long, float, double, real, etc.) with their respective non-trivial instances, as well as representative range types: {arrays, struct ranges, class ranges} x {input, forward, bidirection, ...}, along with non-trivial instances of them. Then provide some generic testing functions that iterate over each of these lists, that user-written unittests can call to instantiate and test their templates with. There can also be a way of adding custom types to the lists, that the generic functions can pick up and include in their combinations to test. But the important thing is to collect these type lists in a single place, so that we can, for example, test std.algorithm functions that expect input ranges with *all* ranges in the input range list, and be reasonably certain that if it all passes, the chances for any more bugs are very slim. (Otherwise, std.algorithm.joiner may have good coverage but std.algorithm.cartesianProduct may have poor coverage, and there's lots of missed reuse opportunities for the test ranges used by the unittests.) T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Mar 14 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
14-Mar-2013 22:55, H. S. Teoh пишет:
 On Thu, Mar 14, 2013 at 10:20:04PM +0400, Dmitry Olshansky wrote:
 14-Mar-2013 22:13, H. S. Teoh пишет:
 On Thu, Mar 14, 2013 at 06:09:26PM +0100, Andrej Mitrovic wrote:
 On 3/14/13, bearophile <bearophileHUGS lycos.com> wrote:
 This is an invalid argument. You can say the same thing for many
 (most?) tests done by the compiler. Unit tests can't be sure to
 verify all code paths inside a function or template.
No, it must do exactly that. If you have so many paths that you can't reasonably test all paths then your template or function is too complicated to begin with. The benefit here of D over C++ is that unit testing is cheap and doesn't require external libraries.
[...] I think you're missing the point. The point is that concepts allow the compiler to deduce template correctness *without* instantiating it with every possible combination of types. Right now, we *don't* have concepts, and therefore the only way to ensure template correctness is to iterate over the exponential number of combinations of template arguments.
And if you create a library tool to try out all sensible combinations would that work for this use case of concepts? In essence you transform concept to some specification and feed it into a CTFE-able generatopr function. Then take the code out and apply mixin it put into a unittest. Sounds easy (if only DMD doesn't run out of memory in the process).
[...] It's certainly possible, I think. Is it worth pursuing? Maybe.
It is as this won't require arguing with Walter, Andrei et al. and the other wopuld either use it or not but you both ways you'd have hard data.
 Here's a
 first crack at it:

 We'd need some way of listing (or generating a list of) all
 representative template arguments, say for example, a listing that
 includes input range, forward range, bidirectional range, etc.. Then we
 need a way to generically generate non-trivial instances of these ranges
 (otherwise the unittest could only cover trivial instances, like empty
 input range, empty forward range, etc., so the template being tested
 will not be verified for non-empty ranges!). The result then will be
 used to instantiate the template and run it through a battery of tests.

 Of course, the ranges themselves have arguments, so you'd need some kind
 of listing of representative types: char, int, float, string, etc., and
 have a way of generating non-trivial instances of each of these types,
 then use them to instantiate the range with. Maybe for each type also
 test it for const(T), immutable(T), etc..

 Then you'd have to cover nested ranges, so you'd need a way to specify
 how deep you want to go (e.g., a recent forward range bug of using =
 instead of .save will only manifest itself if you had a nested range of
 forward ranges -- you couldn't catch that just by running through
 non-nested ranges).

 As you can see, this quickly explodes in exponential number of
 combinations. So ultimately, maybe we still have to resort to
 hand-picked "representative" types.
No - just use some language (DSL!) for the specification instead of generating type-strings. Basically exactly the same thing you'd put into a concept if it was langauge feature. You'd have a spec written in this language per each concept: input range of type X, an infinite range of type Y, an output range for E, etc. Spec states unit tests (and not only) for any type satisfying a concept. The concept (spec) itself is parametrize on types and/or other concepts. Then your tests are kind of monte carlo - pick random (large number) X of full spectrum (infinite on types, but finite on meta-types) of type combinations that this template supports and run the generated unit tests for these. That pick (following the spec) should cover all of the rules in the concept. The types themselves should include dummies generated based on the spec and some real world stuff (predefined).
 But we can do better than the current ad-hoc scheme of writing unittests
 for whatever combination just occurred to the code writer (which usually
 misses a lot of corner cases). We should have a std.unittest module that
 contains lists of all numeric types (byte, int, long, float, double,
 real, etc.) with their respective non-trivial instances, as well as
 representative range types: {arrays, struct ranges, class ranges} x
 {input, forward, bidirection, ...}, along with non-trivial instances of
 them. Then provide some generic testing functions that iterate over each
 of these lists, that user-written unittests can call to instantiate and
 test their templates with.
Exactly. But I'd call for more high-callibre module as in std.testing.spec.
 There can also be a way of adding custom types to the lists, that the
 generic functions can pick up and include in their combinations to test.
 But the important thing is to collect these type lists in a single
 place, so that we can, for example, test std.algorithm functions that
 expect input ranges with *all* ranges in the input range list, and be
 reasonably certain that if it all passes, the chances for any more bugs
 are very slim. (Otherwise, std.algorithm.joiner may have good coverage
 but std.algorithm.cartesianProduct may have poor coverage, and there's
 lots of missed reuse opportunities for the test ranges used by the
 unittests.)
That would be a huge step forward but it's like collecting sets of strings and use their concatenation to define a required set of strings. Instead you could use a formal grammar and define much broader kinds of sets with less "lines"/"rules" (like even regular grammar does). -- Dmitry Olshansky
Mar 14 2013
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 03/14/13 16:05, monarch_dodra wrote:
 On Thursday, 14 March 2013 at 11:04:59 UTC, Artur Skawina wrote:
 On 03/14/13 10:26, Don wrote:
 On Saturday, 9 March 2013 at 03:50:29 UTC, Walter Bright wrote:
 On 3/8/2013 5:19 PM, Brad Anderson wrote:
 On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
      Are they full of it? Has it caused the problems they mention
 in
 D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate static if (along with a third guy). There seems to be a lot of strawman arguments in this paper.
Many of the criticisms in the paper are addressed by our positive experience with static if in D.
I think the hard-to-analyze argument is a good one. I've created an enhancement for some analysis we could do without too much work: http://d.puremagic.com/issues/show_bug.cgi?id=9715 (I think my bug report shows a bigger problem with static if, than is reported in the paper; the problems arise only when you have two static ifs in the same scope).
The gain from such checks would be minimal. Eg "return x.toray;".
I've already found plenty of such bugs in phobos, and wouldn't be surprised if this was one of its bigger sources of bugs. Sure, phobos is template and static "super heavy", given it is more or less the D-STL, but still. If the compiler can statically determine that a template branch simply *can't* compile, then the code should be turned down.
"If'. Sure, it is sometimes able to do that, but often enough this is impossible without actually instantiating the template. And often the error will be trivial to fix (typo etc), so it doesn't really matter. What's left is just a small fraction of all possible errors - catching them is good, but the gain isn't really that large.
 Having to instantiate a template just to check to make sure it is semantically
correct is a huge pain.
Yes, but see above. I'm not saying it shouldn't be done - only that it isn't such a big deal as it is made out to be. For example I'd estimate that most (ie >50%) of my mistakes wouldn't get caught, and I'm not that special. :) artur
Mar 14 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2013 8:05 AM, monarch_dodra wrote:
 Having to instantiate a template just to check to make sure it is semantically
 correct is a huge pain.
I don't understand that sentiment. (You're also mistaken in that only syntactic correctness can be tested in an uninstantiated template, not semantic correctness.) It means you're willing to ship code that is syntactically correct, but is not necessarily semantically correct and is completely untested at runtime. This is not a best practice at all. Also, dmd's -cov coverage testing will check for you what parts of templates were instantiated and what parts never were.
Mar 14 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Artur Skawina:

 The gain from such checks would be minimal. Eg "return 
 x.toray;".
I think we have no statistics about how much gain that's going to give. And even small improvement are good to have, if they are automatic (done by the compiler instead of the programmer), and if they have no false positives. Once such checks are in place, it will be possible to add better checks and further improvements :-) So I think ER 9715 is a good idea. Bye, bearophile
Mar 14 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
09-Mar-2013 05:19, Brad Anderson пишет:
 On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
        See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


       Are they full of it? Has it caused the problems they mention
 in
 D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate static if (along with a third guy).
In fact I'd *love* for C++ to take the concepts-lite path. Why? Because then we can see how it works out for them and probably steal some ideas, of course, porting the to D's static if workhorse. C++14 is just around the corner if they are actually able to ship standards that fast (as they plan). And even if concepts is a failure... well, it's C++ - I couldn't care less :) -- Dmitry Olshansky
Mar 12 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter 
wrote:
        See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg

       Are they full of it? Has it caused the problems they 
 mention
 in
 D?
I think most of the point made in this document are moot. Still static if in D don't define many corner cases that are implementation defined. But that don't change much unless you really go into tricky code. Most static if "just work", so this is really positive at the end !
Mar 08 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 09 Mar 2013 01:48:55 +0100
"DypthroposTheImposter" <mcbracket gmail.com> wrote:

         See the static_if paper here:
 
 http://isocpp.org/forums
 
 Under the post "constraints and static if" there is a link to a
 document about
 static_if
 
 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg
 
        Are they full of it? Has it caused the problems they mention
 in
 D?
Does that document exist somewhere in a the form of a real web page? Or at least *any* real document format?
Mar 08 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 9 Mar 2013 02:08:07 -0500
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 On Sat, 09 Mar 2013 01:48:55 +0100
 "DypthroposTheImposter" <mcbracket gmail.com> wrote:
 
         See the static_if paper here:
 
 http://isocpp.org/forums
 
 Under the post "constraints and static if" there is a link to a
 document about
 static_if
 
 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg
 
        Are they full of it? Has it caused the problems they mention
 in
 D?
Does that document exist somewhere in a the form of a real web page? Or at least *any* real document format?
To be clear, that's not a veiled attack on anything. I really *am* just simply asking if there's a link for that anywhere to a real file (html, pdf, text, wordperfect, gif, hell whatever.)
Mar 08 2013
parent reply 1100110 <0b1100110 gmail.com> writes:
On 03/09/2013 01:33 AM, Nick Sabalausky wrote:
 On Sat, 9 Mar 2013 02:08:07 -0500
 Nick Sabalausky<SeeWebsiteToContactMe semitwist.com>  wrote:

 On Sat, 09 Mar 2013 01:48:55 +0100
 "DypthroposTheImposter"<mcbracket gmail.com>  wrote:

          See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg

         Are they full of it? Has it caused the problems they mention
 in
 D?
Does that document exist somewhere in a the form of a real web page? Or at least *any* real document format?
To be clear, that's not a veiled attack on anything. I really *am* just simply asking if there's a link for that anywhere to a real file (html, pdf, text, wordperfect, gif, hell whatever.)
I converted it to pdf. Do you want it?
Mar 09 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 09 Mar 2013 12:28:37 -0600
1100110 <0b1100110 gmail.com> wrote:

 On 03/09/2013 01:33 AM, Nick Sabalausky wrote:
 On Sat, 9 Mar 2013 02:08:07 -0500
 Nick Sabalausky<SeeWebsiteToContactMe semitwist.com>  wrote:

 On Sat, 09 Mar 2013 01:48:55 +0100
 "DypthroposTheImposter"<mcbracket gmail.com>  wrote:

          See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg

         Are they full of it? Has it caused the problems they
 mention in
 D?
Does that document exist somewhere in a the form of a real web page? Or at least *any* real document format?
To be clear, that's not a veiled attack on anything. I really *am* just simply asking if there's a link for that anywhere to a real file (html, pdf, text, wordperfect, gif, hell whatever.)
I converted it to pdf. Do you want it?
Sure, please. If you could either post it here, or on the web, or email nick1 at semitwist dot com, or whatever works for you that'd be great. :)
Mar 09 2013
parent reply 1100110 <0b1100110 gmail.com> writes:
On 03/09/2013 08:09 PM, Nick Sabalausky wrote:
 On Sat, 09 Mar 2013 12:28:37 -0600
 1100110<0b1100110 gmail.com>  wrote:

 On 03/09/2013 01:33 AM, Nick Sabalausky wrote:
 On Sat, 9 Mar 2013 02:08:07 -0500
 Nick Sabalausky<SeeWebsiteToContactMe semitwist.com>   wrote:

 On Sat, 09 Mar 2013 01:48:55 +0100
 "DypthroposTheImposter"<mcbracket gmail.com>   wrote:

           See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg

          Are they full of it? Has it caused the problems they
 mention in
 D?
Does that document exist somewhere in a the form of a real web page? Or at least *any* real document format?
To be clear, that's not a veiled attack on anything. I really *am* just simply asking if there's a link for that anywhere to a real file (html, pdf, text, wordperfect, gif, hell whatever.)
I converted it to pdf. Do you want it?
Sure, please. If you could either post it here, or on the web, or email nick1 at semitwist dot com, or whatever works for you that'd be great. :)
http://1100110.in/static-if.pdf (Powered by vibe.d =P)
Mar 09 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 10 Mar 2013 00:20:34 -0600
1100110 <0b1100110 gmail.com> wrote:
 
 http://1100110.in/static-if.pdf
 
 (Powered by vibe.d  =P)
Cool, thanks :)
Mar 10 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/8/13 7:48 PM, DypthroposTheImposter wrote:
 See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


 Are they full of it? Has it caused the problems they mention
 in
 D?
Wow. That's quite out of character for Bjarne. I think it's quite a poor piece. Andrei
Mar 09 2013
next sibling parent reply d coder <dlang.coder gmail.com> writes:
Greetings

I believe the paper takes a contrived route to criticize "static if". It
takes some bad code examples which are not obvious use cases of "static if"
and then goes on to say that the resultant code is not good. I think the
code example to begin with was not good.

Regards
- Puneet
Mar 09 2013
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 9 March 2013 at 14:49:36 UTC, d coder wrote:
 Greetings

 I believe the paper takes a contrived route to criticize 
 "static if". It takes some bad code examples which are not 
 obvious use cases of "static if" and then goes on to say that 
 the resultant code is not good. I think the code example to 
 begin with was not good.
Agreed. Just barely started reading it and it appears they're nit-picking about something they would have trouble with if it was scoped or not, but more importantly they aren't considering something we would do automatically. If you declare in one, you declare in the other, only difference may be a few details like storage types, removing some of the problems entirely; So he's attacking something that could be done in the preprocessor anyways; Or maybe he's attacking bad coding style but isn't expressly saying it? [quote] Conditional compilation, the selective inclusion of statements in a translation unit, is a conventional example. Consider a simple example of introducing some declarations, depending on whether the size of some type, T. static if (sizeof(T)==8) { void fun(); void gun(int); } else { void gun(); typedef tx int; } The semantics of the program are this: if sizeof(T)==8, the compiler will parse the statements in the “then” branch, and will tokenize and brace-match the declarations in the else branch. Those other declarations would be uninterpreted by the compiler. Note that unlike normal if statements, the braces enclosing the conditionally compiled statements do not introduce a new scope. Those declarations are declared into the scope enclosing the static if block. This difference makes code written using static if harder to read and understand—modulating between static and non-static ifs in a single block provides ample opportunities for confution and mistakes. The effect of this declaration is to conditionally modify the current scope with a set of new declarations. How can we know, later in the program, which version of gun we should use, or whether tx is defined or not? Any use of those declarations would also need to be wrapped. static if (sizeof(T)==8) gun(32); else gun(); static if (sizeof(T)==8) { long n = x; } static if (sizeof(T)!=8) { tx n = x; } Thus, the use of static_if for conditional compilation is viral. The impact of conditional parsing on program analysis tools is substantial. While the feature may be easily implemented as part of the translation process, program analysis tools have traditionally struggled with conditional declarations. The inclusion of multiple variants (via, e.g., preprocessor conditions) and simultaneous repersentation within a single program model is still an open problem in the source code analysis communities. Adopting static if will make analysis harder, not easier. [/quote] And I'm sure that using the preprocessor keeps things simple right? Geez let's take a C/C++ version of that... Preprocessor tokens may be off, but the point should get across... :P #ifdef X void fun(); void gun(int); #else void gun(); typedef tx int; #endif And #ifdef X gun(32); #else gun(); #endif #ifdef X long n = x; #endif #ifndef X tx n = x; #endif [quote] We have already heard suggestions of static_for and static_while. Can static_switch be far behind? C++ would become a low-level, unprincipled hackers’ favorite playground. In our opinion, if you want compile-time computation, look to constexpr, which does have a sane and typesafe underlying model. If we do not provide a static_for, hackers will simply make one out of static_if or fake equivalents. [/quote] C++ is just as low level as C, this statement is useless. Being against 'static_for' is kinda dumb since if you think about it, it just unrolls the loop ahead of time instead of optimization, other than that it shouldn't do anything odd. I'll agree not to add static_for only because it's not really needed. [quote] The semantics of static_if are to tokenize the branch not taken. If the condition is dependent, as it is in the statements above, then the compiler must not parse either branch. Both branches are tokenized since either one could contain compiler-specific extensions—or both, or neither. That won’t be known until both branches would have been fully parsed. <snip> Consider the real world impact of this design choice. The inability of the compiler to parse the branches of the compiler means that the library writer will need to instantiate every branch of the template just to ensure that the syntax is correct and that no spelling errors have been made. Today, this is done, to a large extent, by the compiler [/quote] In C++ you need to have EVERYTHING loaded (declarations, etc) loaded before you can compile anything, Unlike in D where all tokens effectively have one meaning as intended, so the whole template issues aren't an issue. Seems like they're just opening their own cans of worms :P [quote] The trailing if clause enforces a requirement that T must be convertible to the value_type of I. We most strongly agree that some mechanism is needed for constraining templates, this is particular syntax leaves much to be desired. It is particularly verbose, and leaves the entire body of the template unchecked. The body must only be tokenized because the static condition could guard the instantiation against compiler-specific extensions in the nested code. That fact would only be ascertainable after the entire body is parsed. [/quote] Deja-vu, until recently (C++11) when they changed 'auto' to accept any type didn't they have to be super verbose everywhere anyways? Verboseness shouldn't matter in templates so much as it's user code that needs to be clean. Microsoft core teams admit their STL they write and maintain is ugliest and basically illegible to anyone outside the team; Although template structure as C++ is and their STL doesn't help much. [quote] The static if feature might also be used to support overloading. Below is an implementation of advance. <snip> Because static if only allows for Boolean decisions, overloading on a set of overlapping constraints requires the programmer to write bounding predicates like those above (e.g., input iterator but not bidirectional, bidirectional but not random access, etc...). This model of overloading is brittle, error-prone, verbose, and defines a “closed world”. No other overloads may be considered without modifying the constraints on the existing declarations in order to ensure consistency. Declarations might be condensed using else clauses, but this is only cosmetic. [/quote] *gasp* Walter! Did you know static if only allows boolean decisions! My god our static if MUST is be error-prone and brittle, a 'closed world'! *Note sarcasm* I'll agree a modification for handling nested static if's or something could be nice, but it's not unmanageable if you keep it relatively small. Hell what am I talking about? People go above and beyond a language to do stuff I wouldn't even consider, like a full x86 emulator in JavaScript.. [quote] The use of static if might also be used to reorder data structures for tighter alignment, but this is a potentially dangerous idea that could lead to bugs that are exceptionally difficult to diagnose and fix. [/quote] Doesn't he mean the pre-processor? #define max(x,y) x > y ? x : y int a = 1, b = 2; z = max(a++, b++); struct X { #ifdef TIGHT int x; char y[100]; #else char y[100]; int x; #endif } The largest complaint he has is managing tokens and being able to figure out what is what; In short previous bad decisions on the language HE HIMSELF MADE are preventing potential growth of the language making static if in his mind, unmanageable, yet you can do anything with the preprocessor (well, no CTFE...).
Mar 09 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu 
wrote:
 On 3/8/13 7:48 PM, DypthroposTheImposter wrote:
 See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


 Are they full of it? Has it caused the problems they mention
 in
 D?
Wow. That's quite out of character for Bjarne. I think it's quite a poor piece. Andrei
I think there is a bit of forced bashing in there, but the main point is that static if prevents eager semantic validation of templated code. In C++, if you write a semantically incorrect template, then the compiler can catch it. This is not possible once static ifs enter the picture. I know for a fact I've had the C++ compiler catch a fair amount of errors for me, whereas it takes actual intantiation for the D compiler to catch said errors (and I've seen a few such errors in phobos). I think the main point is not "is static if good or not": I think D has clearly demonstrated how powerful it can be. However, to the question of "is it the right move for C++, whith all of its heritage, to adopt static if?" As a C++ developper, honestly, I'm not sure it is. I think that's where the piece is comming from, in maybe a clumsy manner. C++ took a different road with its "horrible" template syntax, but it took that road. I think it is better to improve that road (with concepts, for example), then try to move the current paradigm. That's might point of view having mostly a "full C++" background, and having learned D. The bottom line, I think, is that it is an error to think of D as "just" improved C++, and that what might work for D might not be what is best for C++. It doesn't mean that static if (or other D constructs) are bad in and out of themselves. I wouldn't take this piece as a "direct attack" on D. ... BTW, in regards to template constraints (not the rest), he does have a point. We have raised the exact same issues here on the boards more than once.
Mar 09 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/9/13 10:22 AM, monarch_dodra wrote:
 BTW, in regards to template constraints (not the rest), he does have a
 point. We have raised the exact same issues here on the boards more than
 once.
What was the problem for D again? Andrei
Mar 09 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 9 March 2013 at 16:05:59 UTC, Andrei Alexandrescu 
wrote:
 On 3/9/13 10:22 AM, monarch_dodra wrote:
 BTW, in regards to template constraints (not the rest), he 
 does have a
 point. We have raised the exact same issues here on the boards 
 more than
 once.
What was the problem for D again? Andrei
"Problem" is a big word. But basically, the combination: "if your template type doesn't meet template constraints, where did it fail?" We don't have that, but concepts do. This is part of the: - Should we use constraints only for overloads or also to validate types? - Should we instead use static asserts to find out why the argument type is wrong? That said, concepts (afaik) don't handle overloads... ...which brings us to managing said overloads. Basically, right now, if you want overloads, you have to repeat the conditions in a: if (a && !b) ... if (b && !c) ... if (c) This is minor, but it does not scale very well, especially if "a", "b" and "c" are complicated. In algorithm, some of our constraints for sort/find can be 5 lines long. At this point, can we still say that they are readable tools for users, or an implementation tool for dispatch? Things can get evenmore hairy,when you are operating on 2 different types. One last thing to keep in mind is that having constraints allows hijacking, whereas concpets/static asserts resolve as an ambigus call. ---- Not a breaking issue or anything, just more of an anoyance. I wanted to point out that we ourselves have already had talks about the points raised in said article. Regardless, that was not the main point that I was trying to get accross. My main point was simply that what works for D might not be best for C++.
Mar 09 2013
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 9 March 2013 at 16:22:43 UTC, monarch_dodra wrote:
 ...which brings us to managing said overloads. Basically, right 
 now, if you want overloads, you have to repeat the conditions 
 in a:

 if (a && !b)
 ...
 if (b && !c)
 ...
 if (c)

 This is minor, but it does not scale very well, especially if 
 "a", "b" and "c" are complicated. In algorithm, some of our 
 constraints for sort/find can be 5 lines long. At this point, 
 can we still say that they are readable tools for users, or an 
 implementation tool for dispatch?
I agree this is a problem. sort didn't have constraints for a long time. I added them not long ago, but if I'm being perfectly honest, I'm not 100% convinced I've done it correctly. It's incredibly difficult to examine a non-trivial function to see what the correct constraints are. btw, you have a bug :-) If the arguments match constraints a and c, but not b then the call will be ambiguous on the first and third. Another problem with constraints is that if you want to add a specialisation, you can't do it without changing the existing functions, e.g. void foo(R)(R r) if (isInputRange!R) If I want to add a better version for random access ranges, I cannot just add: void foo(R)(R r) if (isRandomAccessRange!R) I also have to modify the original: void foo(R)(R r) if (isInputRange!R && !isRandomAccessRange!R) I suppose a better solution to this problem would involve someway of specifying that random access ranges are a subtype of input ranges, and the overload resolution would recognise that the random access range version is preferable to the more general version when available. I can't see a way to do this in general with constraints.
Mar 09 2013
parent reply "TommiT" <tommitissari hotmail.com> writes:
On Saturday, 9 March 2013 at 16:42:56 UTC, deadalnix wrote:
 On Saturday, 9 March 2013 at 15:22:55 UTC, monarch_dodra wrote:
 [..]
 BTW, in regards to template constraints (not the rest), he 
 does have a point. We have raised the exact same issues here 
 on the boards more than once.
The more I think of it, the more this whole duck typing for templates is probably a bad solution because we lack tool to express « meta types ».
I'm starting to think so too. On Saturday, 9 March 2013 at 18:46:23 UTC, Peter Alexander wrote:
 [..]
 I suppose a better solution to this problem would involve 
 someway of specifying that random access ranges are a subtype 
 of input ranges, and the overload resolution would recognise 
 that the random access range version is preferable to the more 
 general version when available.
I wonder how would these "polymorphic concepts" work exactly. The following is pseudo-code: concept A1 { void foo(); } concept A2 : A1 { // A2 extends A1 void bar(); } concept B1 { void fun(); } concept B2 : B1 { void gun(); } struct S1 implements A2 { void foo() { } void bar() { } } struct S2 implements B2 { void fun() { } void gun() { } } void dostuff(A1, B1)(A1 a, B1 b) { } // Overload-1 void dostuff(A2, B1)(A2 a, B1 b) { } // Overload-2 void main() { S1 s1; S2 s2; dostuff(s1, s2); // calls the more specialized Overload-2 } // But, if we add the following overload, then the above // function call dostuff(s1, s2) doesn't know whether to // call Overload-2 or, the equally specialized, Overload-3: void dostuff(A1, B2)(A1 a, B2 b) { } // Overload-3 // And, if we add yet another, more specialized, overload, // then the previous ambiguity goes away: void dostuff(A2, B2)(A2 a, B2 b) { }
Mar 11 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
 On Saturday, 9 March 2013 at 16:42:56 UTC, deadalnix wrote:
 On Saturday, 9 March 2013 at 15:22:55 UTC, monarch_dodra wrote:
 [..]
 BTW, in regards to template constraints (not the rest), he 
 does have a point. We have raised the exact same issues here 
 on the boards more than once.
The more I think of it, the more this whole duck typing for templates is probably a bad solution because we lack tool to express « meta types ».
I'm starting to think so too. On Saturday, 9 March 2013 at 18:46:23 UTC, Peter Alexander wrote:
 [..]
 I suppose a better solution to this problem would involve 
 someway of specifying that random access ranges are a subtype 
 of input ranges, and the overload resolution would recognise 
 that the random access range version is preferable to the more 
 general version when available.
I wonder how would these "polymorphic concepts" work exactly. The following is pseudo-code: concept A1 { void foo(); } concept A2 : A1 { // A2 extends A1 void bar(); } concept B1 { void fun(); } concept B2 : B1 { void gun(); } struct S1 implements A2 { void foo() { } void bar() { } } struct S2 implements B2 { void fun() { } void gun() { } } void dostuff(A1, B1)(A1 a, B1 b) { } // Overload-1 void dostuff(A2, B1)(A2 a, B1 b) { } // Overload-2 void main() { S1 s1; S2 s2; dostuff(s1, s2); // calls the more specialized Overload-2 } // But, if we add the following overload, then the above // function call dostuff(s1, s2) doesn't know whether to // call Overload-2 or, the equally specialized, Overload-3: void dostuff(A1, B2)(A1 a, B2 b) { } // Overload-3 // And, if we add yet another, more specialized, overload, // then the previous ambiguity goes away: void dostuff(A2, B2)(A2 a, B2 b) { }
Yes, that is the idea. It seems really cool.
Mar 11 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2013 8:43 PM, deadalnix wrote:
 Yes, that is the idea. It seems really cool.
It's interfaces without the vtable[]. It's still solely based on type signatures. D constraints make pretty much anything that can be computed at compile time a testable gate.
Mar 11 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 04:34:05 UTC, Walter Bright wrote:
 On 3/11/2013 8:43 PM, deadalnix wrote:
 Yes, that is the idea. It seems really cool.
It's interfaces without the vtable[]. It's still solely based on type signatures. D constraints make pretty much anything that can be computed at compile time a testable gate.
Yes, but that allow static checking. The argument is the same as for dynamic vs static typing. In PHP for instance, you can do thing like : if(is_string($foo)) { // handle the case for string } else { // Do something else } And this is very similar to our template constraint system and static if, except we are meta here (ie, meta dynamic typing vs meta static typing).
Mar 11 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2013 10:49 PM, deadalnix wrote:
 And this is very similar to our template constraint system and static if,
except
 we are meta here (ie, meta dynamic typing vs meta static typing).
The issue I have with it is it is only able to express concepts as types. Values are important, too, as they are also parameters to templates.
Mar 11 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 06:05:54 UTC, Walter Bright wrote:
 On 3/11/2013 10:49 PM, deadalnix wrote:
 And this is very similar to our template constraint system and 
 static if, except
 we are meta here (ie, meta dynamic typing vs meta static 
 typing).
The issue I have with it is it is only able to express concepts as types. Values are important, too, as they are also parameters to templates.
Both definitively have advantages and drawbacks. Does the C++ team have any plan on making concept work with values ? Concepts are for instance THE perfect match for all kind of range we have.
Mar 11 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2013 11:17 PM, deadalnix wrote:
 Both definitively have advantages and drawbacks. Does the C++ team have any
plan
 on making concept work with values ?
I don't know.
 Concepts are for instance THE perfect match for all kind of range we have.
Not for infinite ranges, which depend on empty returning a compile time value.
Mar 11 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 06:34:50 UTC, Walter Bright wrote:
 Not for infinite ranges, which depend on empty returning a 
 compile time value.
It was already discussed int he past that this was a bad idea. I think that is another symptom of that poor design choice than an actual issue with concepts.
Mar 12 2013
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 12 March 2013 at 07:13:11 UTC, deadalnix wrote:
 On Tuesday, 12 March 2013 at 06:34:50 UTC, Walter Bright wrote:
 Not for infinite ranges, which depend on empty returning a 
 compile time value.
It was already discussed int he past that this was a bad idea. I think that is another symptom of that poor design choice than an actual issue with concepts.
When was it discussed that this was a bad idea? I'm not saying it isn't (I think it isn't), but I don't remember any such discussion. I'd love to read it.
Mar 12 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 07:59:49 UTC, monarch_dodra wrote:
 On Tuesday, 12 March 2013 at 07:13:11 UTC, deadalnix wrote:
 On Tuesday, 12 March 2013 at 06:34:50 UTC, Walter Bright wrote:
 Not for infinite ranges, which depend on empty returning a 
 compile time value.
It was already discussed int he past that this was a bad idea. I think that is another symptom of that poor design choice than an actual issue with concepts.
When was it discussed that this was a bad idea? I'm not saying it isn't (I think it isn't), but I don't remember any such discussion. I'd love to read it.
http://forum.dlang.org/thread/yjogdvimxeyxzrjoqzsr forum.dlang.org First answer is yours, BTW :D
Mar 12 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/12/2013 1:14 AM, deadalnix wrote:
 On Tuesday, 12 March 2013 at 07:59:49 UTC, monarch_dodra wrote:
 On Tuesday, 12 March 2013 at 07:13:11 UTC, deadalnix wrote:
 On Tuesday, 12 March 2013 at 06:34:50 UTC, Walter Bright wrote:
 Not for infinite ranges, which depend on empty returning a compile time value.
It was already discussed int he past that this was a bad idea. I think that is another symptom of that poor design choice than an actual issue with concepts.
When was it discussed that this was a bad idea?
http://forum.dlang.org/thread/yjogdvimxeyxzrjoqzsr forum.dlang.org
I don't think that thread conclusively determined it was a bad idea.
Mar 12 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 09:35:51 UTC, Walter Bright wrote:
 On 3/12/2013 1:14 AM, deadalnix wrote:
 On Tuesday, 12 March 2013 at 07:59:49 UTC, monarch_dodra wrote:
 On Tuesday, 12 March 2013 at 07:13:11 UTC, deadalnix wrote:
 On Tuesday, 12 March 2013 at 06:34:50 UTC, Walter Bright 
 wrote:
 Not for infinite ranges, which depend on empty returning a 
 compile time value.
It was already discussed int he past that this was a bad idea. I think that is another symptom of that poor design choice than an actual issue with concepts.
When was it discussed that this was a bad idea?
http://forum.dlang.org/thread/yjogdvimxeyxzrjoqzsr forum.dlang.org
I don't think that thread conclusively determined it was a bad idea.
The thread don't conclude anything. It nevertheless raises very good points.
Mar 12 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/12/2013 12:13 AM, deadalnix wrote:
 On Tuesday, 12 March 2013 at 06:34:50 UTC, Walter Bright wrote:
 Not for infinite ranges, which depend on empty returning a compile time value.
It was already discussed int he past that this was a bad idea. I think that is another symptom of that poor design choice than an actual issue with concepts.
Nevertheless, it shows a weakness of concepts in that concepts are unable to express ideas about values - only types.
Mar 12 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/12/13, deadalnix <deadalnix gmail.com> wrote:
 Concepts are for instance THE perfect match for all kind of range
 we have.
I don't know about that. Consider that with template parameters and static if you can pick and choose which range type you will implement: struct Range(Store) { static if (hasLength!Store) { // implement length, make the range random-access } else { // make the range an input range } } How would you implement this with concepts if you have to put the list of implements at the struct header?
Mar 12 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 07:10:36 UTC, Andrej Mitrovic wrote:
 On 3/12/13, deadalnix <deadalnix gmail.com> wrote:
 Concepts are for instance THE perfect match for all kind of 
 range
 we have.
I don't know about that. Consider that with template parameters and static if you can pick and choose which range type you will implement: struct Range(Store) { static if (hasLength!Store) { // implement length, make the range random-access } else { // make the range an input range } } How would you implement this with concepts if you have to put the list of implements at the struct header?
I was thinking about constraint. I don't think static if should go away in any way.
Mar 12 2013
prev sibling parent reply "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 12 March 2013 at 04:34:05 UTC, Walter Bright wrote:
 It's interfaces without the vtable[].

 It's still solely based on type signatures. D constraints make 
 pretty much anything that can be computed at compile time a 
 testable gate.
Yeah, you're right. That kind of interface syntax doesn't really lend itself to specifying concepts. So, here's another attempt at a concept syntax (and functionality): concept AscendingInfiniteInputRange { // 'this' is an instance of a type which implements the // AscendingInfiniteInputRange concept given the // if-condition below is true: if( is(typeof(this.empty) : bool) && is(typeof(this.front)) && !is(typeof(this.front) == void) && is(typeof(this.popFront() == void) // testing a compile time evaluable value: && this.empty == false // static members can also be tested: && typeof(this).infinite == true && typeof(this).sortedAscending == true ) } // extending the AscendingInfiniteInputRange concept: concept AscendingInfiniteForwardRange : AscendingInfiniteInputRange { if (is(typeof(this.save) == typeof(this))) } // a concept of a 2-dimensional infinite ascending slope: concept InfiniteSlope : AscendingInfiniteForwardRange { // 'is' can be used to test if a type implements a concept: if (is(typeof(this.front) == AscendingInfiniteForwardRange)) }
Mar 12 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 12, 2013 at 12:39:48PM +0100, TommiT wrote:
 On Tuesday, 12 March 2013 at 04:34:05 UTC, Walter Bright wrote:
It's interfaces without the vtable[].

It's still solely based on type signatures. D constraints make
pretty much anything that can be computed at compile time a
testable gate.
Yeah, you're right. That kind of interface syntax doesn't really lend itself to specifying concepts. So, here's another attempt at a concept syntax (and functionality): concept AscendingInfiniteInputRange { // 'this' is an instance of a type which implements the // AscendingInfiniteInputRange concept given the // if-condition below is true: if( is(typeof(this.empty) : bool) && is(typeof(this.front)) && !is(typeof(this.front) == void) && is(typeof(this.popFront() == void) // testing a compile time evaluable value: && this.empty == false // static members can also be tested: && typeof(this).infinite == true && typeof(this).sortedAscending == true ) }
How is this any different from the current isInputRange!R, isForwardRange!R, etc.? T -- Дерево держится корнями, а человек - друзьями.
Mar 12 2013
next sibling parent reply "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 12 March 2013 at 14:16:15 UTC, H. S. Teoh wrote:
 On Tue, Mar 12, 2013 at 12:39:48PM +0100, TommiT wrote:
 On Tuesday, 12 March 2013 at 04:34:05 UTC, Walter Bright wrote:
It's interfaces without the vtable[].

It's still solely based on type signatures. D constraints make
pretty much anything that can be computed at compile time a
testable gate.
Yeah, you're right. That kind of interface syntax doesn't really lend itself to specifying concepts. So, here's another attempt at a concept syntax (and functionality): concept AscendingInfiniteInputRange { // 'this' is an instance of a type which implements the // AscendingInfiniteInputRange concept given the // if-condition below is true: if( is(typeof(this.empty) : bool) && is(typeof(this.front)) && !is(typeof(this.front) == void) && is(typeof(this.popFront() == void) // testing a compile time evaluable value: && this.empty == false // static members can also be tested: && typeof(this).infinite == true && typeof(this).sortedAscending == true ) }
How is this any different from the current isInputRange!R, isForwardRange!R, etc.? T
The difference is in function overload resolution. Polymorphic concept based template would know about the hierarchical nature of the concepts, say ForwardRange is a sub-concept of InputRange, and thus the function overload resolution would be able to choose the template which has the most derived/specialized concept parameter that still matches with the given template argument.
Mar 12 2013
parent "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 12 March 2013 at 14:24:11 UTC, TommiT wrote:
 The difference is in function overload resolution. Polymorphic 
 concept based template would know about the hierarchical nature 
 of the concepts, say ForwardRange is a sub-concept of 
 InputRange, and thus the function overload resolution would be 
 able to choose the template which has the most 
 derived/specialized concept parameter that still matches with 
 the given template argument.
Example: void foo(R)(R) if (isInputRange!R) { } void foo(R)(R) if (isForwardRange!R) { } int[] arr; foo(arr); // ambiguity error // Polymorphic concept to the rescue: concept InputRange { // definition of the concept ... } // ForwardRange is an extension of InputRange concept ForwardRange : InputRange { ... } void bar(InputRange R)(R) { } void bar(ForwardRange R)(R) { } int[] arr; bar(arr); // calls the second one
Mar 12 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 14:16:15 UTC, H. S. Teoh wrote:
 On Tue, Mar 12, 2013 at 12:39:48PM +0100, TommiT wrote:
 On Tuesday, 12 March 2013 at 04:34:05 UTC, Walter Bright wrote:
It's interfaces without the vtable[].

It's still solely based on type signatures. D constraints make
pretty much anything that can be computed at compile time a
testable gate.
Yeah, you're right. That kind of interface syntax doesn't really lend itself to specifying concepts. So, here's another attempt at a concept syntax (and functionality): concept AscendingInfiniteInputRange { // 'this' is an instance of a type which implements the // AscendingInfiniteInputRange concept given the // if-condition below is true: if( is(typeof(this.empty) : bool) && is(typeof(this.front)) && !is(typeof(this.front) == void) && is(typeof(this.popFront() == void) // testing a compile time evaluable value: && this.empty == false // static members can also be tested: && typeof(this).infinite == true && typeof(this).sortedAscending == true ) }
How is this any different from the current isInputRange!R, isForwardRange!R, etc.? T
With the thing defined that way not that much. But consider : concept InputRange(T) { bool empty; T front; void popFront(); } Then you can : - Validate range in a static manner. - Validate template before they are instantiated. - Express intent. - Make overload rules easier to understand and more predictable when used. Definitively the idea it nice. I don't see it a replacement of static if as it doesn't handle values.
Mar 12 2013
parent reply "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 12 March 2013 at 15:10:25 UTC, deadalnix wrote:
 On Tuesday, 12 March 2013 at 14:16:15 UTC, H. S. Teoh wrote:
 On Tue, Mar 12, 2013 at 12:39:48PM +0100, TommiT wrote:
 On Tuesday, 12 March 2013 at 04:34:05 UTC, Walter Bright 
 wrote:
It's interfaces without the vtable[].

It's still solely based on type signatures. D constraints 
make
pretty much anything that can be computed at compile time a
testable gate.
Yeah, you're right. That kind of interface syntax doesn't really lend itself to specifying concepts. So, here's another attempt at a concept syntax (and functionality): concept AscendingInfiniteInputRange { // 'this' is an instance of a type which implements the // AscendingInfiniteInputRange concept given the // if-condition below is true: if( is(typeof(this.empty) : bool) && is(typeof(this.front)) && !is(typeof(this.front) == void) && is(typeof(this.popFront() == void) // testing a compile time evaluable value: && this.empty == false // static members can also be tested: && typeof(this).infinite == true && typeof(this).sortedAscending == true ) }
How is this any different from the current isInputRange!R, isForwardRange!R, etc.? T
With the thing defined that way not that much. But consider : concept InputRange(T) { bool empty; T front; void popFront(); }
What if I write a type like the following: struct MyType { int _value; property bool empty() const { return true; } property ref const(int) front() const { return _value; } void popFront() const { } } Does MyType fulfill the requirements of your InputRange(T) concept? I don't think it does since its front returns by ref const(int) and InputRange(T)'s front returns by value.
Mar 12 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 15:26:19 UTC, TommiT wrote:
 With the thing defined that way not that much. But consider :

 concept InputRange(T) {
    bool empty;
    T front;
    void popFront();
 }
What if I write a type like the following: struct MyType { int _value; property bool empty() const { return true; } property ref const(int) front() const { return _value; } void popFront() const { } } Does MyType fulfill the requirements of your InputRange(T) concept? I don't think it does since its front returns by ref const(int) and InputRange(T)'s front returns by value.
It doesn't because popFront is const and that don't make any sense. But more generally, I wrote that stuff quickly to demonstrate what it could look like and not to provide an accurate definition of InputRange.
Mar 12 2013
parent "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 12 March 2013 at 15:37:01 UTC, deadalnix wrote:
 On Tuesday, 12 March 2013 at 15:26:19 UTC, TommiT wrote:
 With the thing defined that way not that much. But consider :

 concept InputRange(T) {
   bool empty;
   T front;
   void popFront();
 }
What if I write a type like the following: struct MyType { int _value; property bool empty() const { return true; } property ref const(int) front() const { return _value; } void popFront() const { } } Does MyType fulfill the requirements of your InputRange(T) concept? I don't think it does since its front returns by ref const(int) and InputRange(T)'s front returns by value.
It doesn't because popFront is const and that don't make any sense.
I didn't mean to make popFront const. My point was that InputRange concept requires that the front property returns a non-void type but it doesn't care whether or not it is returned by ref, const ref, or by value. I don't see how you could easily convey that kind of requirement in an interface-like syntax.
Mar 12 2013
prev sibling next sibling parent "anonymous" <anonymous example.com> writes:
By now, I'm suspecting that I'm missing the point entirely, but 
here it is.

The idea is this:
Given
     interface A {...}
     interface B : A {...}
     struct S {supposed to implement B}
use alias this to enable implicit conversions:
     S to Concept!(B, S)
     Concept!(B, S) to Concept!(A, S)
The number of alias this hops then decides which overload is 
taken.

No rights reserved.


import std.traits: BaseTypeTuple;

mixin template implements(Iface) {
      property inout(Concept!(Iface, typeof(this))) _concept()() 
inout {
         return typeof(return)(this);
     }
     alias _concept this;

     // ensure that the interface is implemented
     alias typeof(this) Self;
     private class _Tester : Iface {
         Self s;
         mixin ForwardInterface!(s, Iface);
     }
}

struct Concept(Iface, Impl) {
     Impl impl;
     mixin ForwardInterface!(impl, Iface);

     alias BaseTypeTuple!Iface B;
     static if(B.length == 1) {
          property inout(Concept!(B, typeof(impl))) _concept()() 
inout {
             return typeof(return)(impl);
         }
         alias _concept this;
     } else {
         // because multiple alias this aren't here yet
         static assert(B.length == 0);
     }
}

import std.traits: ParameterTypeTuple, ReturnType;
import std.string: format;

mixin template ForwardInterface(alias target, Iface) {
     mixin ForwardMembers!(target, Iface, __traits(allMembers, 
Iface));
}
mixin template ForwardMembers(alias target, Iface, memberNames 
...) {
     static if(memberNames.length > 0) {
         mixin ForwardOverloads!(target, memberNames[0],
             __traits(getOverloads, Iface, memberNames[0]));
         mixin ForwardMembers!(target, Iface, memberNames[1 .. $]);
     }
}
mixin template ForwardOverloads(
     alias target,
     string memberName,
     overloads ...
) {
     static if(overloads.length > 0) {
         alias overloads[0] o;
         mixin(format(
             q{
                 ReturnType!o %1$s(ParameterTypeTuple!o args) 
%2$-(%s %) {
                     target.%1$s(args);
                 }
             },
             memberName,
             [
                 (is(typeof(o) == immutable) ? "immutable" : ""),
                 (is(typeof(o) == const) ? "const" : ""),
                 (is(typeof(o) == shared) ? "shared" : "")
             ]
         ));
         mixin ForwardOverloads!(target, memberName, overloads[1 
.. $]);
     }
}

// example from 
http://forum.dlang.org/post/qqnwpprluchyaphvammf forum.dlang.org

interface A1 {void foo();}
interface A2 : A1 {void bar();}
interface B1 {void fun();}
interface B2 : B1 {void gun();}

struct S1 {
     mixin implements!A2;
     void foo() {}
     void bar() {}
}

struct S2 {
     mixin implements!B2;
     void fun() {}
     void gun() {}
}

int dostuff(X, Y)(Concept!(A1, X) a, Concept!(B1, Y) b) {return 
1;}
int dostuff(X, Y)(Concept!(A2, X) a, Concept!(B1, Y) b) {return 
2;}

import std.stdio;
void main() {
     S1 s1;
     S2 s2;
     writeln(dostuff(s1, s2)); // calls the more specialized 
Overload-2
}

// But, if we add the following overload, then the above
// function call dostuff(s1, s2) doesn't know whether to
// call Overload-2 or, the equally specialized, Overload-3:

int dostuff(X, Y)(Concept!(A1, X) a, Concept!(B2, Y) b) {return 
3;}

// And, if we add yet another, more specialized, overload,
// then the previous ambiguity goes away:

int dostuff(X, Y)(Concept!(A2, X) a, Concept!(B2, Y) b) {return 
4;}
Mar 12 2013
prev sibling parent reply "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
 struct S1 implements A2 {
     void foo() { }
     void bar() { }
 }
That's not good. Types shouldn't have to explicitly say that they implement a concept. The fact that a type implements a concept should be implicit, i.e. the following (pseudo-code) should work: concept InputRange { if( is(typeof(this.empty) : bool) && is(typeof(this.front)) && is(typeof(this.popFront() == void) ) } struct MyRange { bool empty() { return false; } int front() { return 42; } void popFront() { } } void main() { static assert(is(MyRange == InputRange)); }
Mar 12 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 12 Mar 2013 12:51:03 +0100
"TommiT" <tommitissari hotmail.com> wrote:

 On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
 struct S1 implements A2 {
     void foo() { }
     void bar() { }
 }
That's not good. Types shouldn't have to explicitly say that they implement a concept.
I *strongly* disagree. A much as I love ranges (for example), their duckiness is the one thing I consider to be a huge mistake.
Mar 12 2013
parent reply "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 12 March 2013 at 13:44:35 UTC, Nick Sabalausky wrote:
 On Tue, 12 Mar 2013 12:51:03 +0100
 "TommiT" <tommitissari hotmail.com> wrote:

 On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
 struct S1 implements A2 {
     void foo() { }
     void bar() { }
 }
That's not good. Types shouldn't have to explicitly say that they implement a concept.
I *strongly* disagree. A much as I love ranges (for example), their duckiness is the one thing I consider to be a huge mistake.
The problem with having to explicitl specify that a type implements a certain concept, is the resulting strong coupling between the concept definition and the type. This prevents "happy accidents" like the following from happening: Alice and Bob write libraries without knowing anything about each other or each other's code. Alice implements the following in her library: concept IntegerLike { ... } void foo(IntegerLike N)(N n) { } Bob implements the following in his library: struct SafeInt { ... } Later Bob realizes that Alice has written this cool function foo which accepts his type SafeInt as an argument because SafeInt just so happens to fulfill the requirements of the IntegerLike concept defined in Alice's library. Although, the majority of concepts should come from the standard library.
Mar 12 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 12 Mar 2013 16:02:24 +0100
"TommiT" <tommitissari hotmail.com> wrote:

 On Tuesday, 12 March 2013 at 13:44:35 UTC, Nick Sabalausky wrote:
 On Tue, 12 Mar 2013 12:51:03 +0100
 "TommiT" <tommitissari hotmail.com> wrote:

 On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
 struct S1 implements A2 {
     void foo() { }
     void bar() { }
 }
That's not good. Types shouldn't have to explicitly say that they implement a concept.
I *strongly* disagree. A much as I love ranges (for example), their duckiness is the one thing I consider to be a huge mistake.
The problem with having to explicitl specify that a type implements a certain concept, is the resulting strong coupling between the concept definition and the type. This prevents "happy accidents" like the following from happening: Alice and Bob write libraries without knowing anything about each other or each other's code. Alice implements the following in her library: concept IntegerLike { ... } void foo(IntegerLike N)(N n) { } Bob implements the following in his library: struct SafeInt { ... } Later Bob realizes that Alice has written this cool function foo which accepts his type SafeInt as an argument because SafeInt just so happens to fulfill the requirements of the IntegerLike concept defined in Alice's library. Although, the majority of concepts should come from the standard library.
"Happy accidents" is nothing more than another way of saying "Shit fucked up, but by pure dumb luck there was no damage". It's an absolutely *terrible* thing to encourage and design for. You may as well just go dynamic all the way, a la ActionScript 2 or Python - it's all the same "let random things happen by accident and blindly hope it just happens to turn out correct" philosophy. Design-by-accident is an anti-pattern. To me more specific, the problem with duck typing is that it falsely assumes that name+signature uniquely defines semantics (which is clearly not a valid assumption). Avoiding accidental screwups under duck typing *is* feasible if there's only a few well-known duck types that are ever in play (ex: our entire list of available duck types is a handful of phobos-defined ranges and basically nothing else). But it does not scale: The likelihood of accidental fuckups is multiplied with each additional duck type in existence, with non-stdlib duck types carrying a greater "accidental fuck up" weight.
Mar 12 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 12, 2013 at 12:28:07PM -0400, Nick Sabalausky wrote:
 On Tue, 12 Mar 2013 16:02:24 +0100
 "TommiT" <tommitissari hotmail.com> wrote:
 
 On Tuesday, 12 March 2013 at 13:44:35 UTC, Nick Sabalausky wrote:
 On Tue, 12 Mar 2013 12:51:03 +0100
 "TommiT" <tommitissari hotmail.com> wrote:

 On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
 struct S1 implements A2 {
     void foo() { }
     void bar() { }
 }
That's not good. Types shouldn't have to explicitly say that they implement a concept.
I *strongly* disagree. A much as I love ranges (for example), their duckiness is the one thing I consider to be a huge mistake.
The problem with having to explicitl specify that a type implements a certain concept, is the resulting strong coupling between the concept definition and the type. This prevents "happy accidents" like the following from happening: Alice and Bob write libraries without knowing anything about each other or each other's code. Alice implements the following in her library: concept IntegerLike { ... } void foo(IntegerLike N)(N n) { } Bob implements the following in his library: struct SafeInt { ... } Later Bob realizes that Alice has written this cool function foo which accepts his type SafeInt as an argument because SafeInt just so happens to fulfill the requirements of the IntegerLike concept defined in Alice's library. Although, the majority of concepts should come from the standard library.
"Happy accidents" is nothing more than another way of saying "Shit fucked up, but by pure dumb luck there was no damage". It's an absolutely *terrible* thing to encourage and design for. You may as well just go dynamic all the way, a la ActionScript 2 or Python - it's all the same "let random things happen by accident and blindly hope it just happens to turn out correct" philosophy. Design-by-accident is an anti-pattern. To me more specific, the problem with duck typing is that it falsely assumes that name+signature uniquely defines semantics (which is clearly not a valid assumption). Avoiding accidental screwups under duck typing *is* feasible if there's only a few well-known duck types that are ever in play (ex: our entire list of available duck types is a handful of phobos-defined ranges and basically nothing else). But it does not scale: The likelihood of accidental fuckups is multiplied with each additional duck type in existence, with non-stdlib duck types carrying a greater "accidental fuck up" weight.
I see it from another perspective: I've had to deal with proprietary libraries that defined types that couldn't be used with a particular container type, just because the container type expects the item type to implement a particular interface, but it doesn't. But actually, it *does* have the requisite members to implement that interface; it just didn't *say* it implemented that interface. So there's the need for Yet Another Useless Java-style Wrapper Class just to work around this nonsense. Duck-typing solves this problem. Of course, full-out ducktyping has its own problems, like you said; but there needs to be a way of rewriting APIs such that you could say "type T doesn't implement interface I right now, but actually, if you rewrite T.A to T.X and T.B to T.Y, then T implements interface I just fine". Though with D, I suspect this may actually be possible via alias this: struct RewireInterface(T, Interface, Tuple!(string,string)... rewrites) { T t; alias t this; foreach (rewrite; rewrites) { alias rewrite[0] = rewrite[1]; } } OK, maybe not. But the foreach could be replace with a suitable recursive template so that the generated aliases are at the top-level in RewireInterface. Probably some other hack is needed to work around the need for Tuple in the compile-time parameters, which I'm pretty sure DMD rejects right now. But assuming all this can be worked around, you could do something like this: struct StraitJacketedProprietaryItem { int propX() { ... } int propY() { ... } } concept MyInterface { int myX(); int myY(); } alias NonStraitJacketedItem = RewireInterface!( StraitJacketedProprietaryItem, MyInterface, "myX", "propX", "myY", "propY" ); assert(NonStraitJacketedItem implements MyInterface); OK, lots of pseudo-code going on here, but you get the idea. T -- It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.
Mar 12 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 12 Mar 2013 09:57:44 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 On Tue, Mar 12, 2013 at 12:28:07PM -0400, Nick Sabalausky wrote:
 On Tue, 12 Mar 2013 16:02:24 +0100
 "TommiT" <tommitissari hotmail.com> wrote:
 
 On Tuesday, 12 March 2013 at 13:44:35 UTC, Nick Sabalausky wrote:
 On Tue, 12 Mar 2013 12:51:03 +0100
 "TommiT" <tommitissari hotmail.com> wrote:

 On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
 struct S1 implements A2 {
     void foo() { }
     void bar() { }
 }
That's not good. Types shouldn't have to explicitly say that they implement a concept.
I *strongly* disagree. A much as I love ranges (for example), their duckiness is the one thing I consider to be a huge mistake.
The problem with having to explicitl specify that a type implements a certain concept, is the resulting strong coupling between the concept definition and the type. This prevents "happy accidents" like the following from happening: Alice and Bob write libraries without knowing anything about each other or each other's code. Alice implements the following in her library: concept IntegerLike { ... } void foo(IntegerLike N)(N n) { } Bob implements the following in his library: struct SafeInt { ... } Later Bob realizes that Alice has written this cool function foo which accepts his type SafeInt as an argument because SafeInt just so happens to fulfill the requirements of the IntegerLike concept defined in Alice's library. Although, the majority of concepts should come from the standard library.
"Happy accidents" is nothing more than another way of saying "Shit fucked up, but by pure dumb luck there was no damage". It's an absolutely *terrible* thing to encourage and design for. You may as well just go dynamic all the way, a la ActionScript 2 or Python - it's all the same "let random things happen by accident and blindly hope it just happens to turn out correct" philosophy. Design-by-accident is an anti-pattern. To me more specific, the problem with duck typing is that it falsely assumes that name+signature uniquely defines semantics (which is clearly not a valid assumption). Avoiding accidental screwups under duck typing *is* feasible if there's only a few well-known duck types that are ever in play (ex: our entire list of available duck types is a handful of phobos-defined ranges and basically nothing else). But it does not scale: The likelihood of accidental fuckups is multiplied with each additional duck type in existence, with non-stdlib duck types carrying a greater "accidental fuck up" weight.
I see it from another perspective: I've had to deal with proprietary libraries that defined types that couldn't be used with a particular container type, just because the container type expects the item type to implement a particular interface, but it doesn't. But actually, it *does* have the requisite members to implement that interface; it just didn't *say* it implemented that interface. So there's the need for Yet Another Useless Java-style Wrapper Class just to work around this nonsense. Duck-typing solves this problem.
Duck-typing solves that problem at the cost of potentially introducing silent bugs. But who says it can only be solved that way? The problem is trivially solvable *without* the downsides of duck-typing. Just make the ducks explicit instead of implicit. All you need is something analogous to "cast": For example, an "(a|A)ssumeImplements" wrapper. Or maybe even just make it an extra feature of "cast": import std.typecons : assumeImplements, AssumeImplements; concept IBob { Some syntax to require "void bob()" } struct BobType : IBob { void bob() {...} } struct AliceType { void bob() {...} } // *Explicit* duck-typing alias AssumeImplements!(IBob, AliceType) AliceTypeIBob; void useBob(IBob ib) {...} // Or whatever syntax void main() { BobType b; useBob(b); // Ok AliceTypeIBob ab; useBob(ab); // Ok AliceType a; useBob(a); // Fails // Ok, *explicit* duck-typing useBob(assumeImplements!IBob(a)); // Maybe ok, semi-explicit duck-typing useBob(cast(IBob)a); }
 Of course, full-out ducktyping has its own problems, like you said;
 but there needs to be a way of rewriting APIs such that you could say
 "type T doesn't implement interface I right now, but actually, if you
 rewrite T.A to T.X and T.B to T.Y, then T implements interface I just
 fine". Though with D, I suspect this may actually be possible via
 alias this:
 
 	struct RewireInterface(T, Interface, Tuple!(string,string)...
 rewrites) {
 		T t;
 		alias t this;
 		foreach (rewrite; rewrites) {
 			alias rewrite[0] = rewrite[1];
 		}
 	}
 
Interesting.
Mar 12 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 12 March 2013 at 16:59:41 UTC, H. S. Teoh wrote:
 On Tue, Mar 12, 2013 at 12:28:07PM -0400, Nick Sabalausky wrote:
 On Tue, 12 Mar 2013 16:02:24 +0100
 "TommiT" <tommitissari hotmail.com> wrote:
 
 On Tuesday, 12 March 2013 at 13:44:35 UTC, Nick Sabalausky 
 wrote:
 On Tue, 12 Mar 2013 12:51:03 +0100
 "TommiT" <tommitissari hotmail.com> wrote:

 On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
 struct S1 implements A2 {
     void foo() { }
     void bar() { }
 }
That's not good. Types shouldn't have to explicitly say that they implement a concept.
I *strongly* disagree. A much as I love ranges (for example), their duckiness is the one thing I consider to be a huge mistake.
The problem with having to explicitl specify that a type implements a certain concept, is the resulting strong coupling between the concept definition and the type. This prevents "happy accidents" like the following from happening: Alice and Bob write libraries without knowing anything about each other or each other's code. Alice implements the following in her library: concept IntegerLike { ... } void foo(IntegerLike N)(N n) { } Bob implements the following in his library: struct SafeInt { ... } Later Bob realizes that Alice has written this cool function foo which accepts his type SafeInt as an argument because SafeInt just so happens to fulfill the requirements of the IntegerLike concept defined in Alice's library. Although, the majority of concepts should come from the standard library.
"Happy accidents" is nothing more than another way of saying "Shit fucked up, but by pure dumb luck there was no damage". It's an absolutely *terrible* thing to encourage and design for. You may as well just go dynamic all the way, a la ActionScript 2 or Python - it's all the same "let random things happen by accident and blindly hope it just happens to turn out correct" philosophy. Design-by-accident is an anti-pattern. To me more specific, the problem with duck typing is that it falsely assumes that name+signature uniquely defines semantics (which is clearly not a valid assumption). Avoiding accidental screwups under duck typing *is* feasible if there's only a few well-known duck types that are ever in play (ex: our entire list of available duck types is a handful of phobos-defined ranges and basically nothing else). But it does not scale: The likelihood of accidental fuckups is multiplied with each additional duck type in existence, with non-stdlib duck types carrying a greater "accidental fuck up" weight.
I see it from another perspective: I've had to deal with proprietary libraries that defined types that couldn't be used with a particular container type, just because the container type expects the item type to implement a particular interface, but it doesn't. But actually, it *does* have the requisite members to implement that interface; it just didn't *say* it implemented that interface. So there's the need for Yet Another Useless Java-style Wrapper Class just to work around this nonsense. Duck-typing solves this problem. Of course, full-out ducktyping has its own problems, like you said; but there needs to be a way of rewriting APIs such that you could say "type T doesn't implement interface I right now, but actually, if you rewrite T.A to T.X and T.B to T.Y, then T implements interface I just fine". Though with D, I suspect this may actually be possible via alias this: struct RewireInterface(T, Interface, Tuple!(string,string)... rewrites) { T t; alias t this; foreach (rewrite; rewrites) { alias rewrite[0] = rewrite[1]; } } OK, maybe not. But the foreach could be replace with a suitable recursive template so that the generated aliases are at the top-level in RewireInterface. Probably some other hack is needed to work around the need for Tuple in the compile-time parameters, which I'm pretty sure DMD rejects right now. But assuming all this can be worked around, you could do something like this: struct StraitJacketedProprietaryItem { int propX() { ... } int propY() { ... } } concept MyInterface { int myX(); int myY(); } alias NonStraitJacketedItem = RewireInterface!( StraitJacketedProprietaryItem, MyInterface, "myX", "propX", "myY", "propY" ); assert(NonStraitJacketedItem implements MyInterface); OK, lots of pseudo-code going on here, but you get the idea. T
D current compile time capabilities already allow this kind of stuff. I don't see concept as a good idea to introduce into D right now, but definitively something to look at for the future.
Mar 13 2013
prev sibling parent reply "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 12 March 2013 at 16:28:14 UTC, Nick Sabalausky wrote:
 "Happy accidents" is nothing more than another way of saying 
 "Shit
 fucked up, but by pure dumb luck there was no damage". It's an
 absolutely *terrible* thing to encourage and design for. You 
 may as
 well just go dynamic all the way, a la ActionScript 2 or Python 
 - it's
 all the same "let random things happen by accident and blindly 
 hope it
 just happens to turn out correct" philosophy.

 Design-by-accident is an anti-pattern.

 To me more specific, the problem with duck typing is that it 
 falsely
 assumes that name+signature uniquely defines semantics (which is
 clearly not a valid assumption). Avoiding accidental screwups 
 under
 duck typing *is* feasible if there's only a few well-known duck 
 types
 that are ever in play (ex: our entire list of available duck 
 types is a
 handful of phobos-defined ranges and basically nothing else). 
 But it
 does not scale: The likelihood of accidental fuckups is 
 multiplied with
 each additional duck type in existence, with non-stdlib duck 
 types
 carrying a greater "accidental fuck up" weight.
I thought about this a bit more, and I agree with the fundamental content of what you said. The crux of the matter is that we can't specify new semantics with code. We can only specify new semantics through documentation. And compilers don't read documentations. But, I think a good way to alleviate this problem would be to allow programmers to specify that two different concepts are in fact the same exact concept. Then two unrelated libraries could be made interoperable with each other. Example: There are two unrelated libraries, LibA and LibB. Library LibA defines: 1) concept ConceptA { ... } 2) void functionA(ConceptA A)(A a) { ... } Library LibB defines: 1) concept ConceptB { ... } 2) void functionB(ConceptB B)(B b) { ... } The two concepts, ConceptA and ConceptB, specify the same exact concept (this can be verified only by reading their respective documentations). If the end user now creates a type which implements ConceptA: struct MyStruct implements ConceptA { ... } ...then the problem is that instances of MyStruct can't be passed to functionB. But, if the end-user has a way to say that ConceptA is a synonym to ConceptB, then he can make the two libraries interoperable with each other and with his own types. E.g: concept ConceptA = ConceptB; // make them synonymous struct MyStruct implements ConceptA { ... } MyStruct ms; functionB(ms); // OK If ConceptA and ConceptB have happened to use different function names for doing the same conceptual thing, then the end-user should also be able to specify which function names are synonymous with each other.
Mar 12 2013
next sibling parent =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
Just for complete information, the static_if feature isn't rejected but
discussion/effort on it is now delayed.
See minutes: http://isocpp.org/files/papers/N3576.pdf
My understanding is that focusing on concepts(-light) is a priority for
this working group now.

Walter was in the meeting so he got the details.

Joel Lamotte
Mar 13 2013
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 March 2013 08:29, Klaim - Jo=EBl Lamotte <mjklaim gmail.com> wrote:

 Just for complete information, the static_if feature isn't rejected but
 discussion/effort on it is now delayed.
 See minutes: http://isocpp.org/files/papers/N3576.pdf
 My understanding is that focusing on concepts(-light) is a priority for
 this working group now.

 Walter was in the meeting so he got the details.
Looking at the minutes, that was Walter Brown, not Bright. Incase you got confused about the difference. ;) --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Mar 13 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 13 March 2013 at 14:06:33 UTC, Iain Buclaw wrote:
 On 13 March 2013 08:29, Klaim - Joël Lamotte 
 <mjklaim gmail.com> wrote:

 Just for complete information, the static_if feature isn't 
 rejected but
 discussion/effort on it is now delayed.
 See minutes: http://isocpp.org/files/papers/N3576.pdf
 My understanding is that focusing on concepts(-light) is a 
 priority for
 this working group now.

 Walter was in the meeting so he got the details.
Looking at the minutes, that was Walter Brown, not Bright. Incase you got confused about the difference. ;)
Are you saying that Walter Brown isn't bright ? /me runaway
Mar 13 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 March 2013 14:12, deadalnix <deadalnix gmail.com> wrote:

 On Wednesday, 13 March 2013 at 14:06:33 UTC, Iain Buclaw wrote:

 On 13 March 2013 08:29, Klaim - Jo=EBl Lamotte <mjklaim gmail.com> wrote=
:
  Just for complete information, the static_if feature isn't rejected but
 discussion/effort on it is now delayed.
 See minutes: http://isocpp.org/files/**papers/N3576.pdf<http://isocpp.o=
rg/files/papers/N3576.pdf>
 My understanding is that focusing on concepts(-light) is a priority for
 this working group now.

 Walter was in the meeting so he got the details.


  Looking at the minutes, that was Walter Brown, not Bright.  Incase you
got confused about the difference. ;)
Are you saying that Walter Brown isn't bright ? /me runaway
He's neither Black, Blue, or Bubblegum flavour either. --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Mar 13 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2013 8:22 AM, monarch_dodra wrote:
 Things can get evenmore hairy,when you are operating on 2 different types.
This is why complex expressions can be encapsulated as functions.
 One last thing to keep in mind is that having constraints allows hijacking,
 whereas concpets/static asserts resolve as an ambigus call.
I don't see where the hijacking comes in.
Mar 09 2013
next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 10 March 2013 at 02:35:28 UTC, Walter Bright wrote:
 On 3/9/2013 8:22 AM, monarch_dodra wrote:
 Things can get evenmore hairy,when you are operating on 2 
 different types.
This is why complex expressions can be encapsulated as functions.
 One last thing to keep in mind is that having constraints 
 allows hijacking, whereas concpets/static asserts resolve as 
 an ambigus call.
I don't see where the hijacking comes in.
From the bad examples I think he was meaning declaring new functions in the static_if that might not be in the other tree; But proper use of static if doesn't cause those problems.
Mar 10 2013
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 10 March 2013 at 02:35:28 UTC, Walter Bright wrote:
 On 3/9/2013 8:22 AM, monarch_dodra wrote:
 Things can get evenmore hairy,when you are operating on 2 
 different types.
This is why complex expressions can be encapsulated as functions.
Yes, but that doesn't solve the "root" issue of meaningfulness. Sure, instead of having a 5 line constraint, it's only a single line, but are these any better? sort(R, Scheme)(...) if(isRandomAccessRangeWithComparableElementsAndAssignableElementsIfStableSchemeOrSwapableElementsOtherwise!R) or sort(...) if(meetsSortConstraints!R) Neither are really any better for the end user. This is why I don't think constraints should be used at all for validating arguments. [concepts|static asserts] are much better, and when combined with static if, become incredibly powerful: sort(R, Scheme)(...) { static assert (isRandomAccessRange!T); static assert (is(typeof(r.front < r.front))); static if (Scheme == Stable) static assert (hasAssignableElements!T); else static assert (hasSwapableElements!T); //Code Code Code } Much clearer, and the diagnostics much better. That said, we can also look for a "middle ground" where the constraints validate the broad requirements (RA, comparable), and the asserts validate the more complex stuff.
 One last thing to keep in mind is that having constraints 
 allows hijacking,
 whereas concpets/static asserts resolve as an ambigus call.
I don't see where the hijacking comes in.
The problem with contraints is that it merelly eliminates functions from the pool of overloads. If you attemp to call a function with invalid parameters, then you may end up accidentally calling something you didn't want to. Imagine: //---- module a; void do_it(R)(R r) if (isForwardRange!R) { //Do something to r } //---- module b; void do_it(T)(T t) { //Do something completely different } //---- import a, b; void main() { MyInputRange myInputRange; //Oops! I didn't realize it's only input: do_it(myInputRange); //meant to call a.do_it; } //---- With the current scheme of constraints, this will end up calling b.do_it, without any ambiguity. You may or may not consider that is "hijacking", but it is error prone. NOW, if we had defined a.do_it with concepts/static asserts, the programmer would have been served with a "ambiguous call: a.do_it or b.do_it"? So the coder would have to be "alright, I want to explicitly call a.do_it". To which this time the compiler replies "Error: isForwardRange!MyInputRange is false". To which the programmer replies "I understand my error and see what I did wrong". -------------------------------------- I'm not saying template constraints are bad or anything, I think they are incredible tools for dispatching to specialized overloads. However, In regards to *validating* the input, I think concepts/static asserts, are both more robust implementation-wise, while being clearer for the end coder.
Mar 10 2013
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 10 March 2013 at 16:05:37 UTC, monarch_dodra wrote:
 I'm not saying template constraints are bad or anything, I 
 think they are incredible tools for dispatching to specialized 
 overloads.

 However, In regards to *validating* the input, I think 
 concepts/static asserts, are both more robust 
 implementation-wise, while being clearer for the end coder.
+1
Mar 10 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/10/2013 9:05 AM, monarch_dodra wrote:
 Yes, but that doesn't solve the "root" issue of meaningfulness. Sure, instead
of
 having a 5 line constraint, it's only a single line, but are these any better?

 sort(R, Scheme)(...)
 if(isRandomAccessRangeWithComparableElementsAndAssignableElementsIfStableSchemeOrSwapableElementsOtherwise!R)


 or

 sort(...)
      if(meetsSortConstraints!R)

 Neither are really any better for the end user.
I don't think this issue is any different from selecting a name for any function that does something non-trivial. It's why we have functions - to encapsulate complexity.
 This is why I don't think constraints should be used at all for validating
 arguments. [concepts|static asserts] are much better, and when combined with
 static if, become incredibly powerful:

 sort(R, Scheme)(...)
 {
      static assert (isRandomAccessRange!T);
      static assert (is(typeof(r.front < r.front)));
      static if (Scheme == Stable)
          static assert (hasAssignableElements!T);
      else
          static assert (hasSwapableElements!T);

      //Code Code Code
 }

 Much clearer, and the diagnostics much better.
Whether it's clearer or not is all in how you choose to organize/write them. Also, the static assert model does not enter into overload selection, while constraints do.
 One last thing to keep in mind is that having constraints allows hijacking,
 whereas concpets/static asserts resolve as an ambigus call.
I don't see where the hijacking comes in.
The problem with contraints is that it merelly eliminates functions from the pool of overloads. If you attemp to call a function with invalid parameters, then you may end up accidentally calling something you didn't want to. Imagine: //---- module a; void do_it(R)(R r) if (isForwardRange!R) { //Do something to r } //---- module b; void do_it(T)(T t) { //Do something completely different } //---- import a, b; void main() { MyInputRange myInputRange; //Oops! I didn't realize it's only input: do_it(myInputRange); //meant to call a.do_it; } //---- With the current scheme of constraints, this will end up calling b.do_it, without any ambiguity. You may or may not consider that is "hijacking", but it is error prone.
That is not hijacking. Hijacking is when a template or function **from an unrelated scope** matches better and steals the call away. When templates/functions are in the same scope, it is just a usual overloading issue. It's not an undue burden on the programmer to pay attention to the overloads in the same scope. He's got to do that anyway.
Mar 10 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 9 March 2013 at 15:22:55 UTC, monarch_dodra wrote:
 On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu 
 wrote:
 On 3/8/13 7:48 PM, DypthroposTheImposter wrote:
 See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to 
 a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


 Are they full of it? Has it caused the problems they mention
 in
 D?
Wow. That's quite out of character for Bjarne. I think it's quite a poor piece. Andrei
I think there is a bit of forced bashing in there, but the main point is that static if prevents eager semantic validation of templated code. In C++, if you write a semantically incorrect template, then the compiler can catch it. This is not possible once static ifs enter the picture. I know for a fact I've had the C++ compiler catch a fair amount of errors for me, whereas it takes actual intantiation for the D compiler to catch said errors (and I've seen a few such errors in phobos). I think the main point is not "is static if good or not": I think D has clearly demonstrated how powerful it can be. However, to the question of "is it the right move for C++, whith all of its heritage, to adopt static if?" As a C++ developper, honestly, I'm not sure it is. I think that's where the piece is comming from, in maybe a clumsy manner. C++ took a different road with its "horrible" template syntax, but it took that road. I think it is better to improve that road (with concepts, for example), then try to move the current paradigm. That's might point of view having mostly a "full C++" background, and having learned D. The bottom line, I think, is that it is an error to think of D as "just" improved C++, and that what might work for D might not be what is best for C++. It doesn't mean that static if (or other D constructs) are bad in and out of themselves. I wouldn't take this piece as a "direct attack" on D. ... BTW, in regards to template constraints (not the rest), he does have a point. We have raised the exact same issues here on the boards more than once.
The more I think of it, the more this whole duck typing for templates is probably a bad solution because we lack tool to express « meta types ».
Mar 09 2013
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu 
wrote:
 Wow. That's quite out of character for Bjarne. I think it's 
 quite a poor piece.
I agree. I stopped reading at "The purpose of this paper is to examine the negative impact of the static if proposal [...]". Not "the impact", but "the *negative* impact". That doesn't exactly set the stage for a very nuanced discussion. Lars
Mar 09 2013
prev sibling next sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu 
wrote:
 On 3/8/13 7:48 PM, DypthroposTheImposter wrote:
 See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


 Are they full of it? Has it caused the problems they mention
 in
 D?
Wow. That's quite out of character for Bjarne. I think it's quite a poor piece. Andrei
Indeed, from the start, it doesn't seem to give a fair assessment of the value of the feature. As for rejecting your proposal, don't take it too personnally. In the contrary, the inclusion of static if would have been the single reason for C++ users not to migrate en masse to D. Think that there won't be a good solution for C++ before another 20 years. By the time it is proposed, this is a good opportunity for D to mature and conquer hearts.
Mar 10 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 10 March 2013 at 22:49:53 UTC, SomeDude wrote:
 On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu 
 wrote:
 On 3/8/13 7:48 PM, DypthroposTheImposter wrote:
 See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to 
 a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


 Are they full of it? Has it caused the problems they mention
 in
 D?
Wow. That's quite out of character for Bjarne. I think it's quite a poor piece. Andrei
Indeed, from the start, it doesn't seem to give a fair assessment of the value of the feature. As for rejecting your proposal, don't take it too personnally. In the contrary, the inclusion of static if would have been the single reason for C++ users not to migrate en masse to D. Think that there won't be a good solution for C++ before another 20 years. By the time it is proposed, this is a good opportunity for D to mature and conquer hearts.
Concepts have some drawbacks, but are also supperior in many way to static if. This isn't a black and white situation.
Mar 10 2013
prev sibling parent "so" <so so.so> writes:
On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu 
wrote:

 Wow. That's quite out of character for Bjarne. I think it's 
 quite a poor piece.

 Andrei
I simply didn't have the stomach to read it after the first paragraph. They have no idea what they are talking about. It is as if they never used templates more than writing one liners. Harder to read, understand, debug? I am just speechless.
Mar 11 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/09/2013 01:48 AM, DypthroposTheImposter wrote:
         See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


        Are they full of it?
Maybe. The paper is full of typos.
 Has it caused the problems they mention in D?
All of the non-C++ specific ones that are not made up to make the paper longer. Eg: 0. Templates + static if are an ad-hoc abstraction mechanism. 1. Declaration-site template body type checking becomes undecidable. 2. Constraint-based overloading needs manual work in order to express specialization relations. In D there also exist other problems that wouldn't occur in C++ in that form: static if(!is(typeof(x))) enum y = 1; static if(!is(typeof(y))) enum z = 2; static if(!is(typeof(z))) enum x = 3; The above currently does not have any defined behaviour. If the three are distributed to mutually importing modules, which constants get defined may depend on the order the modules are passed to DMD on the command line. (It is solvable, but so far few people have shown interest.)
Mar 09 2013
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter 
wrote:
        See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg

       Are they full of it? Has it caused the problems they 
 mention
 in
 D?
It is hard for me to say, they continued to bring up that they have better tools to achieve some of the items (constexsp) but don't give an example of what that code would look like. It seems like they aren't actually looking for serious discussion on the matter; "C++ would become a low-level, unprincipled, hackers’ favorite playground." as apposed to what it is now a low-level, unprincipled, playground no hacker would play in unless they had to? That combined with not wanting to include a "realtively simple-to-use new feature" really makes it hard to take the paper seriously. As for template constraints, we do have issues in D; monarch_dodra has been good to go over those. I'm glad we have them, but they are not without their faults.
Mar 10 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, March 09, 2013 01:48:55 DypthroposTheImposter wrote:
         See the static_if paper here:
 
 http://isocpp.org/forums
 
 Under the post "constraints and static if" there is a link to a
 document about
 static_if
 
 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3
 NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg
 
        Are they full of it? Has it caused the problems they mention
 in
 D?
I haven't read the paper, so I really don't know what problems they see with static if, and C++ _is_ a very different beast than D (particularly with regards to stuff done at compile time), but without statif if, C++ seems very crippled with regards to templates and conditional compilaton. The combination of template constraints and static ifs is _extremely_ powerful in D, and it works very well. C++ currently lacks anything of the sort, and until it does, it's templates will be very much inferior to D's. Maybe they can gain similar power through different mechanisms, but I'm surprised that anyone would think that static if was such a bad idea. It's working fantastically well for us, and I don't know how we'd get along without it. - Jonathan M Davis
Mar 10 2013
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 11 March 2013 at 02:39:47 UTC, Jonathan M Davis wrote:
 I haven't read the paper, so I really don't know what problems 
 they see with static if, and C++ _is_ a very different beast 
 than D (particularly with regards to stuff done at compile 
 time), but without statif if, C++ seems very crippled with 
 regards to templates and conditional compilaton. The 
 combination of template constraints and static ifs is 
 _extremely_ powerful in D, and it works very well. C++ 
 currently lacks anything of the sort, and until it does, it's 
 templates will be very much inferior to D's. Maybe they can 
 gain similar power through different mechanisms, but I'm 
 surprised that anyone would think that static if was such a bad 
 idea. It's working fantastically well for us, and I don't know 
 how we'd get along without it.
It basically comes down to syntactical analysis, being able to tell if code is written right (when blocks end as well), which goes with their templates and use of <>'s; Which I'm glad to see D isn't crippled in that way. The another part is how static if becomes 'viral' as you'd have to use 'static if' in every spot elsewhere in order to keep it in line; However the example shown is bad programming practice and; You can duplicate very easily using the preprocessor. A third part of it was how 'verbose' they would have to be to check constraints, but with how just before C++11 they were verbose everywhere, so why it is verbose in constraints as his problem I am not sure.
Mar 10 2013
prev sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter
wrote:
        See the static_if paper here:

 http://isocpp.org/forums

 Under the post "constraints and static if" there is a link to a
 document about
 static_if

 https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg

       Are they full of it? Has it caused the problems they 
 mention
 in
 D?
What an unfair article. I guess someone is angry at D. I don't think C++11 is that good an upgrade. Concepts were delayed. Lambdas can't be templated, can't be recursive. constexpr is useless compared to CTFE. Move semantics are easy to use but much harder to really understand. I recently had to duplicate inline assembly code in C++. I would not have been forced to do it in D since (naked inline assembly + static if) can save a lot of lines. static if allow to get polymorphism at finer granularities.
Mar 11 2013