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

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).

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.

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)

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

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

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

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.parseDeclarationOrExpression!(__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.parseDeclarationOrExpression!(__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).

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.

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