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