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

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.

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.

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.

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

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.

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.

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

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

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