On Thu, 21 May 2015 09:58:16 -0400 Steven Schveighoffer via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
> 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 import std.stdio; void f(T:T*)(T* t) { writeln("before change this is not called"); } void f(T)(T t) { writeln("before change this is called"); } void main() { int val; f(&val); f!(int*)(&val); } now it prints: before change this is called before change this is not called but if we make change as you suggest this will be print: before change this is not called before change this is not called