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@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"?
A possible explanation is that the specialization doesn't resolve to a
*specific type* but instead resolves to a *flavor of type*.
For example, does this work?
foo(T : int*)(T t)
That would make some sense at least, but I don't understand why this
rule is in place.
-Steve
