Template type deduction and specialization

Daniel Kozák via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu May 21 06:12:20 PDT 2015


On Thu, 21 May 2015 08:54:54 -0400
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn at puremagic.com> wrote:

> On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote:
> >
> > On Wed, 20 May 2015 17:23:05 -0700
> > Ali Çehreli via Digitalmars-d-learn
> > <digitalmars-d-learn at puremagic.com> wrote:
> >
> >> On 05/20/2015 04:10 PM, Mike Parker wrote:
> >>> On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote:
> >>>> DOC say  `may not have` not `must not have` ;-)
> >>>>
> >>>
> >>> OK, if that's the intent, it needs to be reworded. As it stands,
> >>> it looks more like it's saying specialization is not permissible,
> >>> rather than what "might" be possible.
> >>
> >> That's the only meaning that I get: The doc means "must not". Yet,
> >> as you've shown, the behavior does not match the doc.
> >>
> >> Ali
> >>
> > 1.) we could fix just doc - easiest, but inconsistent
> 
> Before doing this, we have to understand what works and what doesn't. 
> It's not clear to me.
> 
> > 2.) remove implicit deduction even for fun(T:char)(T c) and all
> > other specialization - code breakage so imho not good
> 
> I don't think this is possible, this would break lots of existing
> code.
> 
> > 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2
> 
> I agree with this fix. I don't understand why specialization should 
> disqualify IFTI. Can someone explain this rationale besides "because
> the docs say so"?
> 

But this will break more code than 2. So it is impossible to fix it.



More information about the Digitalmars-d-learn mailing list