No longer possible to define a function `String`

[lgoettgens]

The following code snippet currently behaves differently between 1.11 and nightly:

julia> module Foo
         String(i::Int) = i
       end
Main.Foo

julia> Foo.String === String
false   # 1.11
true    # nightly

A real-world example of this is oscar-system/GAP.jl#1146 (comment). In the submodule GAP.Wrappers of GAP.jl, we create julia wrapper functions around GAP functions using a @wrap macro, and we keep the function names from GAP.
GAP has a function named String, so we create a function GAP.Wrappers.String, which worked for the last years, but no longer in nightly. There, this instead creates a new method for Core.String.

I bisected this to #57253 by @Keno.

[Keno]

This behavior used to be underspecified because it depends on the resolvedness of the binding

julia> module Foo
            @isdefined(String)
            String(i::Int) = i
       end

julia> Foo.String === String
true

As described in the PR, that notion has been removed in 1.12 and the behavior you want now needs to be selected explicitly:

julia> module Foo
       global String
       String(i::Int) = i
       end
Main.Foo

julia> Foo.String === String
false

[lgoettgens]

Thanks for the pointer, that's something I can work with, see oscar-system/GAP.jl#1147.

Could you please make sure that this is documented somewhere for people with similar problems, e.g. in History.md? Once that is done, this issue can be closed.

[vtjnash]

@Keno this seems like a bug though, since extending a function which isn't already imported (merely exported) is supposed to force a new binding (act as if global String was called to soft-resolve it) to prevent accidental merging of unrelated functions

[Keno]

The issue is that String is a type, which has special logic of not needing to be explicitly or implicitly imported to be extended (#25744). We could drop that or restrict it to only cases where the import was not explicit.

[fingolfin]

We tripped over this special logic recently: in a package we already had function Float64(x::OurType). A student added function ComplexF64(x::OurType) next to it. The former worked the latter not. We eventually figured out that this is because Float64 is a type and gets special treatment, while ComplexF64 is merely a "type alias" and apparently does not. I wish this wart was not there.

Alas changing this most likely would break a lot of packages.

But I wonder if the change discussed here doesn't also break a lot of packages? It certainly broke GAP.jl. Maybe we just had bad luck -- but still, doesn't NanoSoldier exist to trst such things? It wasn't tun on #57253

[Keno]

We decided not to run pkgeval on the individual components of that change, since some amount of breakage was expected and we wanted to get everything in for the 1.12 alpha, which is getting pkgeval runs anyway.

[Keno]

I played with the semantics here some more, but the nasty thing is that existing code is relying on this in both directions, although more commonly existing code expects this to extend the constructor (since types are much more common at top level and thus resolve the binding). I do agree though that there's something problematic here, so my current thought is to keep the existing behavior but give a warning telling people to disambiguate explicitly.