September 12, 2013 Re: finding errors with templates without instantiating them | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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
|
September 12, 2013 Re: finding errors with templates without instantiating them | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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
|
September 12, 2013 Re: finding errors with templates without instantiating them | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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.
|
September 13, 2013 Re: finding errors with templates without instantiating them | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
Copyright © 1999-2021 by the D Language Foundation