www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - finding errors with templates without instantiating them

reply Timothee Cour <thelastmammoth gmail.com> writes:
--001a11c1caee579a2904e5a60c7a
Content-Type: text/plain; charset=ISO-8859-1

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
}
----

--001a11c1caee579a2904e5a60c7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Currently D will compile templated code that is synta=
ctically correct but semantically always incorrect (ie regardless of templa=
te parameters), eg the following:</div><div>regardless of T, b is not in sc=
ope and hence this template cannot be instantiated without CT error.</div>
<div><br></div><div>So would it be possible to detect such kind of errors (=
ie CT error regardless of template params) without having to instantiate th=
e template? Sure this could be detected with unittests in a perfect world b=
ut that gives an additional level of safety.</div>
<div><br></div><div>Likewise with template constraints, where the code woul=
dn&#39;t be able to compile given template constraints, but this case is ha=
rder.</div><div><br></div><div>----</div><div>void fun(T)(){</div><div>
=A0 int a=3Db;</div><div>}</div><div><br></div><div>void main(){</div><div>=
=A0 //fun!double; //uncomment for CT error</div><div>}</div><div><div>----<=
/div></div><div><br></div></div>

--001a11c1caee579a2904e5a60c7a--
Sep 05 2013
next sibling 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 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 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 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
prev sibling 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 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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