-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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.
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
call overloading, and make constructors use it #8712
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…call(f, x...) as a fallback (if f is not a function); to do: update inference, fallback to call when f is a type
Conflicts: src/codegen.cpp test/core.jl
Conflicts: base/base.jl test/core.jl
- look up call in the right module instead of using jl_call_func - some inference support for call overloading - pass `call` to _apply and kwcall so they use the containing module's definition - deprecate explicit apply(), rename the builtin to _apply
Conflicts: base/deprecated.jl base/inference.jl
this does not work yet, but gets past the first bootstrap stage. so far this is a significant net simplification.
REPL now works with sys0.ji
…pes in Base this allows the full build to go through
… generated `call` methods
- make typeintersect((Rational{T},T),(Rational{Integer},Int)) == (Rational{Integer},Int) This used to be Bottom, since the T's had to match exactly. Now if T appears in covariant position, subtypes can also match. This is a good change anyway, but turns out to be necessary for the new constructor design. We have a constructor `Rational{T}(x::T, y::T)` which now gets lowered to `call{T}(::Type{Rational{T}}, x::T, y::T)`, so obviously we must allow x and y to be any subtypes of T. This also allows convert_default to be replaced with `convert{T}(::Type{T}, x::T) = x` (to be done next). - making that work required an improved constraint solving algorithm in type intersection. the new algorithm should be much more robust, but it yields more typevars in its answers, for example `typeintersect((T,AbstractArray{T}),(Any,Array{Number,1}))` gives `(_<:Number,Array{Number,1})`. Hopefully this will not cause problems. But I can imagine doing a post-processing step to replace `_<:T` in covariant position with just `T`. In the meantime, to further legitimize such results I also made the next change: - make TypeVar a subtype of Type
…ng convert_default
another Core.convert method to prevent types from old Base from leaking in
…tructors Conflicts: src/codegen.cpp
This was referenced Oct 23, 2014
[PkgEval] ArrayViews may have a testing issue on Julia 0.4 (2014-10-23)
JuliaArrays/ArrayViews.jl#16
Closed
Closed
stevengj
added a commit
to stevengj/julia
that referenced
this pull request
Oct 31, 2014
This was referenced Nov 26, 2014
I don't think this is documented yet, but I might have missed it. If it indeed needs to be done, I guess we should open a new issue. |
This was referenced Jan 8, 2015
stevengj
added a commit
to stevengj/julia
that referenced
this pull request
Apr 29, 2016
StefanKarpinski
added a commit
that referenced
this pull request
Apr 29, 2016
regression test for #8712
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Behold, after a week of red Xes, the tests are passing.
This replaces #8008 and also redesigns constructors to use
call
overloading instead of having some types magically also be generic functions.An inner constructor looks like
and an outer constructor looks like
Now you can also have things that are in-between, for example this
SubArray
constructor:Notice
new{...}
has been added and is needed in cases like this.Of course, you can also define constructors for abstract types which should be helpful in several cases that have come up over time.
An interesting side effect of this change is that this:
now correctly implements "conversions" to supertypes (e.g.
convert(Number, 1)
).This raises several interesting discussion questions that have not been resolved yet:
Callable
type? Maybe makeFunction
an abstract type instead?call
fall back toconvert
, and also tocall
in lower-level modules (see WIP: Call overload #8008 (comment))?Int8(x)
be vectorized?