On 5/21/15 9:14 AM, Daniel Kozak wrote:
On Thursday, 21 May 2015 at 13:12:36 UTC, Daniel Kozák wrote:
On Thu, 21 May 2015 08:54:54 -0400
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn@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@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.
Not more, but it will be worst, because it could change behaviour of
program without error message
How so? My understanding is that it's illegal to call a function with
specializations when IFTI is involved. This means code that currently
doesn't compile, will compile. But what working code base has
non-compiling code? I guess some __traits(compiles) calls would change,
but I don't see the harm in this? You can call the function with an
explicit instantiation, calling it with an implicit one isn't going to
change the semantic meaning of the call.
In other words, code that does this:
foo(x);
that doesn't compile, will start to compile as if you did:
foo!(typeof(x))(x).
How does this break code?
And how does it break more code than 2?
-Steve
