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

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

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

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.

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.

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.

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.

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

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.

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.