Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Extending a constructor is possible without explicit import or module prefix #25744

Open
KristofferC opened this issue Jan 25, 2018 · 4 comments
Open

Extending a constructor is possible without explicit import or module prefix #25744

KristofferC opened this issue Jan 25, 2018 · 4 comments
Assignees
@JeffBezanson
Labels
bug Indicates an unexpected problem or unintended behavior modules types and dispatch Types, subtyping and method dispatch
Milestone
Potential 2.0

Comments

@KristofferC
Copy link
Member

KristofferC commented Jan 25, 2018 •
edited
Loading

Not sure if this is intended:

julia> UUID
ERROR: UndefVarError: UUID not defined

julia> using Random: UUID

julia> UUID(x::String) = UUID(rand(UInt128)) # OK?
UUID

julia> UUID("foo")
8c68d00a-33d1-777d-c4a1-0a41759d1581

julia> using Base: getindex

julia> struct Foo end

julia> getindex(::Foo) = print("Hello")
ERROR: error in method definition: function Base.getindex must be explicitly imported to be extended
@KristofferC KristofferC changed the title Extending a constructor is possible with only using using Extending a constructor is possible with only using using Jan 26, 2018
@JeffBezanson JeffBezanson added modules types and dispatch Types, subtyping and method dispatch labels Sep 4, 2018
@JeffBezanson JeffBezanson mentioned this issue Sep 4, 2018
Closed
@JeffBezanson JeffBezanson self-assigned this Sep 4, 2018
@KristofferC KristofferC mentioned this issue Sep 28, 2020
Closed
@KristofferC
Copy link
Member Author

Ref #37783 which has the extra bonus of having a const => = Pair making it even harder to spot.

@StefanKarpinski StefanKarpinski added the bug Indicates an unexpected problem or unintended behavior label Sep 29, 2020
@KristofferC KristofferC mentioned this issue Mar 2, 2021
Closed
@KristofferC KristofferC added this to the 2.0 milestone Mar 3, 2021
@nickrobinson251
Copy link
Contributor

Can this not be in a v1.x release, if we consider it to be a bug? (And subject to PkgEval telling us it's not relied on too much)

@simeonschaub simeonschaub mentioned this issue Mar 5, 2021
Closed
@KristofferC KristofferC mentioned this issue Dec 9, 2021
Closed
@KristofferC KristofferC removed this from the 2.0 milestone Jan 18, 2023
@KristofferC KristofferC mentioned this issue Jan 18, 2023
Closed
@KristofferC KristofferC changed the title Extending a constructor is possible with only using using Extending a constructor is possible without explicit import or module prefix Jan 18, 2023
@LilithHafner
Copy link
Member

I agree that this is a bug. It's been reported as an issue at least 5 times for the constructor =>, alone.
#37783, #39929, #42552, #43379, #48332

@LilithHafner
Copy link
Member

Fixing this in 1.x would be way too breaking. LinearAlgebra defines Matrix(A::Symmetric). SparseArrays defines Vector(x::AbstractSparseVector{Tv}) where Tv, SharedArrays defines Array(S::SharedArray) = S.s, and that's just in the standard library.

Nevertheless, I think it is acceptable to patch the => case alone because a) it's' is likely way less breaking and b) that is what people complain about because accidentally redefining a => b breaks the REPL and crashes Julia.

@LilithHafner LilithHafner added this to the 2.0 milestone Apr 15, 2023
@LilithHafner LilithHafner mentioned this issue Apr 15, 2023
Merged
@KristofferC KristofferC mentioned this issue Sep 11, 2023
Closed
@KristofferC KristofferC mentioned this issue Jun 10, 2024
Closed
@Keno Keno mentioned this issue Jun 29, 2024
Open
@Keno Keno mentioned this issue Feb 6, 2025
Closed
Keno added a commit that referenced this issue Feb 7, 2025
@Keno
Add a warning for auto-import of types
bab77c4 
This adds a warning for the auto-import of types cases (#25744) that
we have long considered a bit of a bug, but didn't want to change because
it is too breaking.

The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently
and implicitly imported binding. There are two options:

1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.

Historically, case 1 has the additional complication that this
error'd unless `f` is a type. It is my impression that a lot
of existing code did not have a particularly good understanding
of the resolved-ness dependence of this behavior.

However, because case 1 errors for generic functions, it appears
that existing code generally expects case 2. On the other hand,
for types, there is existing code in both directions (#57290 is
an example of case 2; see #57302 for examples of case 1). That
said, case 1 is more common (because types tend to be resolved
because they're used in signatures at toplevel).

Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose
case 2 for functions and case 1 for types. This inconsistency is
unfortunate, but I tried resolving this in either way (making
all situations case 1 or all case 2) and the result was too breaking.

Nevertheless, it is problematic that there is existing code that
expects case 2 beavior for types and we should help users to know
what the correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
   since we generally consider the #25744 case a bug.

Example:
```
julia> module Foo
         String(i::Int) = i
       end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```
@Keno Keno mentioned this issue Feb 7, 2025
Merged
Keno added a commit that referenced this issue Feb 7, 2025
@Keno
Add a warning for auto-import of types
4b55689 
This adds a warning for the auto-import of types cases (#25744) that
we have long considered a bit of a bug, but didn't want to change because
it is too breaking.

The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently
and implicitly imported binding. There are two options:

1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.

Historically, case 1 has the additional complication that this
error'd unless `f` is a type. It is my impression that a lot
of existing code did not have a particularly good understanding
of the resolved-ness dependence of this behavior.

However, because case 1 errors for generic functions, it appears
that existing code generally expects case 2. On the other hand,
for types, there is existing code in both directions (#57290 is
an example of case 2; see #57302 for examples of case 1). That
said, case 1 is more common (because types tend to be resolved
because they're used in signatures at toplevel).

Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose
case 2 for functions and case 1 for types. This inconsistency is
unfortunate, but I tried resolving this in either way (making
all situations case 1 or all case 2) and the result was too breaking.

Nevertheless, it is problematic that there is existing code that
expects case 2 beavior for types and we should help users to know
what the correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
   since we generally consider the #25744 case a bug.

Example:
```
julia> module Foo
         String(i::Int) = i
       end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```
Keno added a commit that referenced this issue Feb 8, 2025
@Keno
Add a warning for auto-import of types
4c0bff4 
This adds a warning for the auto-import of types cases (#25744) that
we have long considered a bit of a bug, but didn't want to change because
it is too breaking.

The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently
and implicitly imported binding. There are two options:

1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.

Historically, case 1 has the additional complication that this
error'd unless `f` is a type. It is my impression that a lot
of existing code did not have a particularly good understanding
of the resolved-ness dependence of this behavior.

However, because case 1 errors for generic functions, it appears
that existing code generally expects case 2. On the other hand,
for types, there is existing code in both directions (#57290 is
an example of case 2; see #57302 for examples of case 1). That
said, case 1 is more common (because types tend to be resolved
because they're used in signatures at toplevel).

Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose
case 2 for functions and case 1 for types. This inconsistency is
unfortunate, but I tried resolving this in either way (making
all situations case 1 or all case 2) and the result was too breaking.

Nevertheless, it is problematic that there is existing code that
expects case 2 beavior for types and we should help users to know
what the correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
   since we generally consider the #25744 case a bug.

Example:
```
julia> module Foo
         String(i::Int) = i
       end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```
Keno added a commit that referenced this issue Feb 8, 2025
@Keno
Add a warning for auto-import of types
ecb068f 
This adds a warning for the auto-import of types cases (#25744) that
we have long considered a bit of a bug, but didn't want to change because
it is too breaking.

The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently
and implicitly imported binding. There are two options:

1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.

Historically, case 1 has the additional complication that this
error'd unless `f` is a type. It is my impression that a lot
of existing code did not have a particularly good understanding
of the resolved-ness dependence of this behavior.

However, because case 1 errors for generic functions, it appears
that existing code generally expects case 2. On the other hand,
for types, there is existing code in both directions (#57290 is
an example of case 2; see #57302 for examples of case 1). That
said, case 1 is more common (because types tend to be resolved
because they're used in signatures at toplevel).

Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose
case 2 for functions and case 1 for types. This inconsistency is
unfortunate, but I tried resolving this in either way (making
all situations case 1 or all case 2) and the result was too breaking.

Nevertheless, it is problematic that there is existing code that
expects case 2 beavior for types and we should help users to know
what the correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
   since we generally consider the #25744 case a bug.

Example:
```
julia> module Foo
         String(i::Int) = i
       end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```
Keno added a commit that referenced this issue Feb 8, 2025
@Keno
Add a warning for auto-import of types
045c5c0 
This adds a warning for the auto-import of types cases (#25744) that
we have long considered a bit of a bug, but didn't want to change because
it is too breaking.

The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently
and implicitly imported binding. There are two options:

1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.

Historically, case 1 has the additional complication that this
error'd unless `f` is a type. It is my impression that a lot
of existing code did not have a particularly good understanding
of the resolved-ness dependence of this behavior.

However, because case 1 errors for generic functions, it appears
that existing code generally expects case 2. On the other hand,
for types, there is existing code in both directions (#57290 is
an example of case 2; see #57302 for examples of case 1). That
said, case 1 is more common (because types tend to be resolved
because they're used in signatures at toplevel).

Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose
case 2 for functions and case 1 for types. This inconsistency is
unfortunate, but I tried resolving this in either way (making
all situations case 1 or all case 2) and the result was too breaking.

Nevertheless, it is problematic that there is existing code that
expects case 2 beavior for types and we should help users to know
what the correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
   since we generally consider the #25744 case a bug.

Example:
```
julia> module Foo
         String(i::Int) = i
       end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```
Keno added a commit that referenced this issue Feb 8, 2025
@Keno
Add a warning for auto-import of types
fad2f2a 
This adds a warning for the auto-import of types cases (#25744) that
we have long considered a bit of a bug, but didn't want to change because
it is too breaking.

The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently
and implicitly imported binding. There are two options:

1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.

Historically, case 1 has the additional complication that this
error'd unless `f` is a type. It is my impression that a lot
of existing code did not have a particularly good understanding
of the resolved-ness dependence of this behavior.

However, because case 1 errors for generic functions, it appears
that existing code generally expects case 2. On the other hand,
for types, there is existing code in both directions (#57290 is
an example of case 2; see #57302 for examples of case 1). That
said, case 1 is more common (because types tend to be resolved
because they're used in signatures at toplevel).

Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose
case 2 for functions and case 1 for types. This inconsistency is
unfortunate, but I tried resolving this in either way (making
all situations case 1 or all case 2) and the result was too breaking.

Nevertheless, it is problematic that there is existing code that
expects case 2 beavior for types and we should help users to know
what the correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
   since we generally consider the #25744 case a bug.

Example:
```
julia> module Foo
         String(i::Int) = i
       end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```
Keno added a commit that referenced this issue Feb 10, 2025
@Keno
Add a warning for auto-import of types
2f9435f 
This adds a warning for the auto-import of types cases (#25744) that
we have long considered a bit of a bug, but didn't want to change because
it is too breaking.

The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently
and implicitly imported binding. There are two options:

1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.

Historically, case 1 has the additional complication that this
error'd unless `f` is a type. It is my impression that a lot
of existing code did not have a particularly good understanding
of the resolved-ness dependence of this behavior.

However, because case 1 errors for generic functions, it appears
that existing code generally expects case 2. On the other hand,
for types, there is existing code in both directions (#57290 is
an example of case 2; see #57302 for examples of case 1). That
said, case 1 is more common (because types tend to be resolved
because they're used in signatures at toplevel).

Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose
case 2 for functions and case 1 for types. This inconsistency is
unfortunate, but I tried resolving this in either way (making
all situations case 1 or all case 2) and the result was too breaking.

Nevertheless, it is problematic that there is existing code that
expects case 2 beavior for types and we should help users to know
what the correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
   since we generally consider the #25744 case a bug.

Example:
```
julia> module Foo
         String(i::Int) = i
       end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```
Keno added a commit that referenced this issue Feb 10, 2025
@Keno
Add a warning for auto-import of types
294b765 
This adds a warning for the auto-import of types cases (#25744) that
we have long considered a bit of a bug, but didn't want to change because
it is too breaking.

The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently
and implicitly imported binding. There are two options:

1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.

Historically, case 1 has the additional complication that this
error'd unless `f` is a type. It is my impression that a lot
of existing code did not have a particularly good understanding
of the resolved-ness dependence of this behavior.

However, because case 1 errors for generic functions, it appears
that existing code generally expects case 2. On the other hand,
for types, there is existing code in both directions (#57290 is
an example of case 2; see #57302 for examples of case 1). That
said, case 1 is more common (because types tend to be resolved
because they're used in signatures at toplevel).

Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose
case 2 for functions and case 1 for types. This inconsistency is
unfortunate, but I tried resolving this in either way (making
all situations case 1 or all case 2) and the result was too breaking.

Nevertheless, it is problematic that there is existing code that
expects case 2 beavior for types and we should help users to know
what the correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
   since we generally consider the #25744 case a bug.

Example:
```
julia> module Foo
         String(i::Int) = i
       end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```
Keno added a commit that referenced this issue Feb 10, 2025
@Keno
Add a warning for auto-import of types (#57311)
8c62f42 
This adds a warning for the auto-import of types cases (#25744) that we
have long considered a bit of a bug, but didn't want to change because
it is too breaking.

The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently and
implicitly imported binding. There are two options:

1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.

Historically, case 1 has the additional complication that this error'd
unless `f` is a type. It is my impression that a lot of existing code
did not have a particularly good understanding of the resolved-ness
dependence of this behavior.

However, because case 1 errors for generic functions, it appears that
existing code generally expects case 2. On the other hand, for types,
there is existing code in both directions (#57290 is an example of case
2; see #57302 for examples of case 1). That said, case 1 is more common
(because types tend to be resolved because they're used in signatures at
toplevel).

Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose case 2 for
functions and case 1 for types. This inconsistency is unfortunate, but I
tried resolving this in either way (making all situations case 1 or all
case 2) and the result was too breaking.

Nevertheless, it is problematic that there is existing code that expects
case 2 beavior for types and we should help users to know what the
correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
since we generally consider the #25744 case a bug.

Example:
```
julia> module Foo
         String(i::Int) = i
       end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```
KristofferC pushed a commit that referenced this issue Feb 11, 2025
@Keno @KristofferC
Add a warning for auto-import of types (#57311)
da6ee02 
This adds a warning for the auto-import of types cases (#25744) that we
have long considered a bit of a bug, but didn't want to change because
it is too breaking.

The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently and
implicitly imported binding. There are two options:

1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.

Historically, case 1 has the additional complication that this error'd
unless `f` is a type. It is my impression that a lot of existing code
did not have a particularly good understanding of the resolved-ness
dependence of this behavior.

However, because case 1 errors for generic functions, it appears that
existing code generally expects case 2. On the other hand, for types,
there is existing code in both directions (#57290 is an example of case
2; see #57302 for examples of case 1). That said, case 1 is more common
(because types tend to be resolved because they're used in signatures at
toplevel).

Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose case 2 for
functions and case 1 for types. This inconsistency is unfortunate, but I
tried resolving this in either way (making all situations case 1 or all
case 2) and the result was too breaking.

Nevertheless, it is problematic that there is existing code that expects
case 2 beavior for types and we should help users to know what the
correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
since we generally consider the #25744 case a bug.

Example:
```
julia> module Foo
         String(i::Int) = i
       end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```

(cherry picked from commit 8c62f42)
@nsajko nsajko mentioned this issue Feb 14, 2025
Merged
dlfivefifty pushed a commit to JuliaArrays/LazyArrays.jl that referenced this issue Feb 15, 2025
@nsajko
Explicitly import ArrayLayouts.MemoryLayout (#366)
f47da84 
* Explicitly import `ArrayLayouts.MemoryLayout`

Prevent name ambiguity, adapt to changes in nightly Julia, preventing a
warning during precompilation.

See:
* JuliaLang/julia#25744
* JuliaLang/julia#57290
* JuliaLang/julia#57311

* apply suggestion
nsajko added a commit to nsajko/ColorTypes.jl that referenced this issue Feb 27, 2025
@nsajko
explicitly qualify Tuple while adding method
59c19d7 
Prevent name ambiguity, adapt to changes in nightly Julia, preventing a
warning during precompilation.

See:
* JuliaLang/julia#25744
* JuliaLang/julia#57290
* JuliaLang/julia#57311
This was referenced Feb 27, 2025
Open
Merged
nsajko added a commit to nsajko/IntervalSets.jl that referenced this issue Feb 27, 2025
@nsajko
explicitly qualify Bool while adding method
c2045d9 
Prevent name ambiguity warning during precompilation on nightly Julia.

See:
* JuliaLang/julia#25744
* JuliaLang/julia#57290
* JuliaLang/julia#57311
@nsajko nsajko mentioned this issue Feb 27, 2025
Open
OlivierHnt pushed a commit to JuliaIntervals/IntervalArithmetic.jl that referenced this issue Feb 27, 2025
@nsajko
explicitly qualify Bool while adding method (#699)
9be6094 
Prevent name ambiguity warning during precompilation on nightly Julia.

See:
* JuliaLang/julia#25744
* JuliaLang/julia#57290
* JuliaLang/julia#57311
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@JeffBezanson JeffBezanson

Labels
bug Indicates an unexpected problem or unintended behavior modules types and dispatch Types, subtyping and method dispatch
Projects
None yet
Milestone
Potential 2.0
Development

No branches or pull requests
5 participants
@StefanKarpinski @JeffBezanson @KristofferC @nickrobinson251 @LilithHafner