www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - finding errors with templates without instantiating them

reply Timothee Cour <thelastmammoth gmail.com> writes:
Currently D will compile templated code that is syntactically correct but
semantically always incorrect (ie regardless of template parameters), eg
the following:
regardless of T, b is not in scope and hence this template cannot be
instantiated without CT error.

So would it be possible to detect such kind of errors (ie CT error
regardless of template params) without having to instantiate the template?
Sure this could be detected with unittests in a perfect world but that
gives an additional level of safety.

Likewise with template constraints, where the code wouldn't be able to
compile given template constraints, but this case is harder.

----
void fun(T)(){
  int a=b;
}

void main(){
  //fun!double; //uncomment for CT error
}
----
Sep 05 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Timothee Cour:


 Currently D will compile templated code that is syntactically 
 correct but
 semantically always incorrect (ie regardless of template 
 parameters), eg
 the following:
 regardless of T, b is not in scope and hence this template 
 cannot be
 instantiated without CT error.

 So would it be possible to detect such kind of errors (ie CT 
 error
 regardless of template params) without having to instantiate 
 the template?


There was a discussion about related matters, and there is an 
enhancement request on this in Bugzilla. Andrei was against it, 
but lot of other people, me and perhaps Walter too have 
appreciated the idea.

Bye,
bearophile
Sep 11 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/11/13 2:53 PM, bearophile wrote:

 Timothee Cour:


 Currently D will compile templated code that is syntactically correct but
 semantically always incorrect (ie regardless of template parameters), eg
 the following:
 regardless of T, b is not in scope and hence this template cannot be
 instantiated without CT error.

 So would it be possible to detect such kind of errors (ie CT error
 regardless of template params) without having to instantiate the
 template?


 There was a discussion about related matters, and there is an
 enhancement request on this in Bugzilla. Andrei was against it, but lot
 of other people, me and perhaps Walter too have appreciated the idea.

 Bye,
 bearophile


I'm not against it, but I find it a very small improvement. Its user 
base is exactly people who want to write and deploy a template without 
ever testing it at all, ever. I have a hard time catering to that 
hypothetical crowd.


Andrei
Sep 11 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 11, 2013 15:15:39 Andrei Alexandrescu wrote:

 I'm not against it, but I find it a very small improvement. Its user
 base is exactly people who want to write and deploy a template without
 ever testing it at all, ever. I have a hard time catering to that
 hypothetical crowd.


That crowd deserves whatever bugs they get.

- Jonathan M Davis
Sep 11 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 11 September 2013 at 22:22:46 UTC, Jonathan M Davis 
wrote:

 On Wednesday, September 11, 2013 15:15:39 Andrei Alexandrescu 
 wrote:

 I'm not against it, but I find it a very small improvement. 
 Its user
 base is exactly people who want to write and deploy a template 
 without
 ever testing it at all, ever. I have a hard time catering to 
 that
 hypothetical crowd.


 That crowd deserves whatever bugs they get.

 - Jonathan M Davis


*cough* Phobos is that crowd *cough*

Seriously. Most new code is tested, however, there is a ton of 
older code that is not only not-tested, but not even *compiled*: 
https://github.com/D-Programming-Language/phobos/pull/1514

Not that I'm necessarily *for* said feature, but I think we need 
to re-evaluate who this "hypothetical crowd" is, before looking 
down on it.
Sep 12 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, September 12, 2013 11:59:52 monarch_dodra wrote:

 On Wednesday, 11 September 2013 at 22:22:46 UTC, Jonathan M Davis
 
 wrote:

 On Wednesday, September 11, 2013 15:15:39 Andrei Alexandrescu
 
 wrote:

 I'm not against it, but I find it a very small improvement.
 Its user
 base is exactly people who want to write and deploy a template
 without
 ever testing it at all, ever. I have a hard time catering to
 that
 hypothetical crowd.


 
 That crowd deserves whatever bugs they get.
 
 - Jonathan M Davis


 
 *cough* Phobos is that crowd *cough*
 
 Seriously. Most new code is tested, however, there is a ton of
 older code that is not only not-tested, but not even *compiled*:
 https://github.com/D-Programming-Language/phobos/pull/1514
 
 Not that I'm necessarily *for* said feature, but I think we need
 to re-evaluate who this "hypothetical crowd" is, before looking
 down on it.


I don't think that there's any question that we've had some fairly poor 
testing of a lot of templates in the past, but you have to do that testing 
regardless if you want to make sure that your code is valid. So, best case, 
this feature would point out that you were too negligent to even bother 
testing beyond maybe the most basic of tests. I really don't think that it's 
worth the extra complication in the compiler and the additional cost to the 
compiler developers' time, particularly when it's likely to introduce new bugs 
that would have to be fixed when we already have plenty of way more important 
issues that still need to be fixed.

I think that if this sort of thing is to be considered, it needs to be 
considered after all of the far more major issues have been resolved.

- Jonathan M Davis
Sep 12 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 I think that if this sort of thing is to be considered, it 
 needs to be
 considered after all of the far more major issues have been 
 resolved.


In general this a well know fallacious point of view. I D there 
are large issues open since several years. If you apply your idea 
to this situation along the years, then you don't improve the 
compiler much
In most jobs you use pipelining: you don't wait for the largest 
jobs to finish before doing small jobs. You try to cram as many 
jobs in parallel as possible, filling all the empty cracks, to 
increase throughput. This is why people are improving small 
things in dmd even if large compiler issues are still present.

Bye,
bearophile
Sep 12 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/12/2013 3:16 PM, bearophile wrote:

 Jonathan M Davis:


 I think that if this sort of thing is to be considered, it needs to be
 considered after all of the far more major issues have been resolved.


 In general this a well know fallacious point of view. I D there are large
issues
 open since several years. If you apply your idea to this situation along the
 years, then you don't improve the compiler much
 In most jobs you use pipelining: you don't wait for the largest jobs to finish
 before doing small jobs. You try to cram as many jobs in parallel as possible,
 filling all the empty cracks, to increase throughput. This is why people are
 improving small things in dmd even if large compiler issues are still present.


Except that this is a large job, with a high likelihood of causing other 
unanticipated issues.
Sep 12 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, September 12, 2013 15:58:05 Walter Bright wrote:

 On 9/12/2013 3:16 PM, bearophile wrote:

 Jonathan M Davis:

 I think that if this sort of thing is to be considered, it needs to be
 considered after all of the far more major issues have been resolved.


 
 In general this a well know fallacious point of view. I D there are large
 issues open since several years. If you apply your idea to this situation
 along the years, then you don't improve the compiler much
 In most jobs you use pipelining: you don't wait for the largest jobs to
 finish before doing small jobs. You try to cram as many jobs in parallel
 as possible, filling all the empty cracks, to increase throughput. This
 is why people are improving small things in dmd even if large compiler
 issues are still present.


 Except that this is a large job, with a high likelihood of causing other
 unanticipated issues.


Yeah. This sounds like exactly the sort of thing that's going to result in a 
lot of additional bugs, and it's arguably going to yield only a minor benefit.

- Jonathan M Davis
Sep 12 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/11/2013 3:15 PM, Andrei Alexandrescu wrote:

 I'm not against it, but I find it a very small improvement. Its user base is
 exactly people who want to write and deploy a template without ever testing it
 at all, ever. I have a hard time catering to that hypothetical crowd.


I'm against it because it makes for a rather bastardized semantic pass - 
expensive to specify, write and debug, and as you point out of highly suspect
merit.

Note that even so, uninstantiated D templates must lex and parse correctly 
regardless.
Sep 11 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 12 September 2013 at 05:04:29 UTC, Walter Bright 
wrote:

 On 9/11/2013 3:15 PM, Andrei Alexandrescu wrote:

 I'm not against it, but I find it a very small improvement. 
 Its user base is
 exactly people who want to write and deploy a template without 
 ever testing it
 at all, ever. I have a hard time catering to that hypothetical 
 crowd.


 I'm against it because it makes for a rather bastardized 
 semantic pass - expensive to specify, write and debug, and as 
 you point out of highly suspect merit.


Isn't that more or less required already for IFTI ?
Sep 11 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/11/2013 10:14 PM, deadalnix wrote:

 On Thursday, 12 September 2013 at 05:04:29 UTC, Walter Bright wrote:

 On 9/11/2013 3:15 PM, Andrei Alexandrescu wrote:

 I'm not against it, but I find it a very small improvement. Its user base is
 exactly people who want to write and deploy a template without ever testing it
 at all, ever. I have a hard time catering to that hypothetical crowd.


 I'm against it because it makes for a rather bastardized semantic pass -
 expensive to specify, write and debug, and as you point out of highly suspect
 merit.


 Isn't that more or less required already for IFTI ?


IFTI requires that the signature be analyzed, not the body.
Sep 11 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Tudor Andrei Cristian Alexandrescu:


 I'm not against it, but I find it a very small improvement. Its 
 user base is exactly people who want to write and deploy a 
 template without ever testing it at all, ever. I have a hard 
 time catering to that hypothetical crowd.


This is an interesting discussion topic.

Mistakes and bugs are mechanically caught at several different 
moments, sometimes even before compile-time, thanks to squiggly 
red lines shown by the IDEs where there's a syntax error. Then 
bugs are found during compilations, by contracts and unittests at 
run-time, etc.

If you have a significant amount of template code already 
written, with unittests, etc, then the small amount of bugs 
spotted by this enhancement request is not much significant, 
because at that stage of the development of the code you are 
supposed to catch the remaining bugs using a high coverage ratio 
of unittests, etc. So in this case I agree with you this feature 
is not much useful, or it could even be harmful if programmers 
trust it too much.

But there is a another situation, when you don't have much new 
code written. You have just written 5-15 lines of templated code, 
and you have not yet written unittests on it (I write lot of 
unittests, but usually after writing the code), at this early 
stage I think it's useful to have a D compiler that performs 
simple analysis of the template code, to catch the simple 
mistakes very quickly. This helps me focus on the less obvious 
errors, and then I can write the unittests to catch the semantic 
mistakes of the code.

So I think this feature is not useful the seasoned code you seem 
to refer to; it's useful to catch as soon as possible silly 
mistakes inside just written templated code, that allows the 
programmer to focus on the less obvious bugs and on writing the 
unittests with high coverage.

Bye,
bearophile
Sep 12 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/12/13 9:53 AM, bearophile wrote:

 But there is a another situation, when you don't have much new code
 written. You have just written 5-15 lines of templated code, and you
 have not yet written unittests on it (I write lot of unittests, but
 usually after writing the code), at this early stage I think it's useful
 to have a D compiler that performs simple analysis of the template code,
 to catch the simple mistakes very quickly. This helps me focus on the
 less obvious errors, and then I can write the unittests to catch the
 semantic mistakes of the code.

 So I think this feature is not useful the seasoned code you seem to
 refer to; it's useful to catch as soon as possible silly mistakes inside
 just written templated code, that allows the programmer to focus on the
 less obvious bugs and on writing the unittests with high coverage.


I don't buy this. All that work for a fleeting moment. Reminds me of 
that comedic bit - hands-free sanitizer dispensers are for the fraction 
of a second between your hand pushing on the button and your hand 
getting cleaned.

Andrei
Sep 12 2013