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

Disallow construction of NTuple from > N elements #40495

Open
jakobnissen opened this issue Apr 15, 2021 · 2 comments · May be fixed by #53265
Open

Disallow construction of NTuple from > N elements #40495

jakobnissen opened this issue Apr 15, 2021 · 2 comments · May be fixed by #53265
Labels
collections Data structures holding multiple items, e.g. sets

Comments

@jakobnissen
Copy link
Member

Currently, you can construct NTuples for any iterable with more than N elements:

julia> NTuple{1}("hello")
('h',)

julia> NTuple{3}(1:5)
(1, 2, 3)

This strikes me as problematic, and an easy way of getting into trouble. If the user tries to create NTuple from something with more than N elements, they probably made a mistake. It would be much nicer if it behaved like:

julia> NTuple{3}(1:5)
ERROR: ArgumentError: too many elements for tuple type Tuple{T} where T
Stacktrace:
 [1] _totuple_err(T::Any)
   @ Base ./tuple.jl:309

(or similar). In practice, this could be done by simply verifying that the iterator returns nothing before returning the tuple.

This change is breaking, but it may be worth considering for a future, breaking release, but perhaps the issue can be solved in a non-breaking way somehow.
@goretkin
Copy link
Contributor

Related: #37132

@jakobnissen jakobnissen mentioned this issue Jan 18, 2024
Open
@nsajko nsajko added the collections Data structures holding multiple items, e.g. sets label Jan 18, 2024
@nsajko
Copy link
Contributor

nsajko commented Jan 18, 2024

This is only "breaking" in the sense that fixing it could break some user code that depends on the current, buggy, behavior; however the buggy behavior was never documented. So I think the buggy behavior is not supported and I don't think that fixing it should necessarily be considered as breaking. Does Julia have some backwards compatibility promise document? Perhaps such a document would have answers to questions like this one, if it exists?

nsajko added a commit to nsajko/julia that referenced this issue Feb 9, 2024
@nsajko
improve construction of <:Tuple types from iterators
8e8d931 
Make tuple construction from overlong iterators throw instead of
truncating the input iterator.

Fixes JuliaLang#40495

Fixes JuliaLang#52657

Make tuple construction from known constant-length iterators inferrable
and prevent allocation.

Fixes JuliaLang#52993

Compute more accurate tuple element types in many cases using
`typeintersect`, with a fallback to the old behavior. This prevents
some cases of `convert` throwing due to ambiguity.

Instead of just calling `typeintersect` on the tuple types, do
`typeintersect` again once `fieldtype` computes the element type.

Fixes JuliaLang#53181

Separate the tuple construction from tuple element conversion, allowing
dropping the `tuple_type_tail` dependency.

Fixes JuliaLang#53182

Trying to construct a tuple from an infinite iterator now results in an
`ArgumentError` instead of in a `MethodError`.
@nsajko nsajko linked a pull request Feb 9, 2024 that will close this issue
Draft
nsajko added a commit to nsajko/julia that referenced this issue Feb 9, 2024
@nsajko
improve construction of <:Tuple types from iterators
db79bff 
Make tuple construction from overlong iterators throw instead of
truncating the input iterator.

Fixes JuliaLang#40495

Fixes JuliaLang#52657

Make tuple construction from known constant-length iterators inferrable
and prevent allocation.

Fixes JuliaLang#52993

Compute more accurate tuple element types in many cases using
`typeintersect`, with a fallback to the old behavior. This prevents
some cases of `convert` throwing due to ambiguity.

Instead of just calling `typeintersect` on the tuple types, do
`typeintersect` again once `fieldtype` computes the element type.

Fixes JuliaLang#53181

Separate the tuple construction from tuple element conversion, allowing
dropping the `tuple_type_tail` dependency.

Fixes JuliaLang#53182

Trying to construct a tuple from an infinite iterator now throws an
`ArgumentError` instead of succeeding or throwing a `MethodError`.
nsajko added a commit to nsajko/julia that referenced this issue Feb 9, 2024
@nsajko
improve construction of <:Tuple types from iterators
912e445 
Make tuple construction from overlong iterators throw instead of
truncating the input iterator.

Fixes JuliaLang#40495

Fixes JuliaLang#52657

Make tuple construction from known constant-length iterators inferrable
and prevent allocation.

Fixes JuliaLang#52993

Compute more accurate tuple element types in many cases using
`typeintersect`, with a fallback to the old behavior. This prevents
some cases of `convert` throwing due to ambiguity.

Instead of just calling `typeintersect` on the tuple types, do
`typeintersect` again once `fieldtype` computes the element type.

Fixes JuliaLang#53181

Separate the tuple construction from tuple element conversion, allowing
dropping the `tuple_type_tail` dependency.

Fixes JuliaLang#53182

Trying to construct a tuple from an infinite iterator now throws an
`ArgumentError` instead of succeeding or throwing a `MethodError`.
nsajko added a commit to nsajko/julia that referenced this issue Feb 9, 2024
@nsajko
improve construction of <:Tuple types from iterators
aaf9ebd 
Make tuple construction from overlong iterators throw instead of
truncating the input iterator.

Fixes JuliaLang#40495

Fixes JuliaLang#52657

Make tuple construction from known constant-length iterators inferrable
and prevent allocation.

Fixes JuliaLang#52993

Compute more accurate tuple element types in many cases using
`typeintersect`, with a fallback to the old behavior. This prevents
some cases of `convert` throwing due to ambiguity.

Instead of just calling `typeintersect` on the tuple types, do
`typeintersect` again once `fieldtype` computes the element type.

Fixes JuliaLang#53181

Separate the tuple construction from tuple element conversion, allowing
dropping the `tuple_type_tail` dependency.

Fixes JuliaLang#53182

Trying to construct a tuple from an infinite iterator now throws an
`ArgumentError` instead of succeeding or throwing a `MethodError`.
nsajko added a commit to nsajko/julia that referenced this issue Feb 9, 2024
@nsajko
improve construction of <:Tuple types from iterators
d4127a7 
Make tuple construction from overlong iterators throw instead of
truncating the input iterator.

Trying to construct a tuple from an infinite iterator now throws an
`ArgumentError` instead of succeeding or throwing a `MethodError`.

Fixes JuliaLang#40495

Fixes JuliaLang#52657

Make tuple construction from known constant-length iterators inferrable
and prevent allocation.

Fixes JuliaLang#52993

Compute more accurate tuple element types in many cases using
`typeintersect`, with a fallback to the old behavior. This prevents
some cases of `convert` throwing due to ambiguity.

Instead of just calling `typeintersect` on the tuple types, do
`typeintersect` again once `fieldtype` computes the element type.

Fixes JuliaLang#53181

Separate the tuple construction from tuple element conversion, allowing
dropping the `tuple_type_tail` dependency.

Fixes JuliaLang#53182
nsajko added a commit to nsajko/julia that referenced this issue Feb 9, 2024
@nsajko
improve construction of <:Tuple types from iterators
039fc1b 
Make tuple construction from overlong iterators throw instead of
truncating the input iterator.

Trying to construct a tuple from an infinite iterator now throws an
`ArgumentError` instead of succeeding or throwing a `MethodError`.

Fixes JuliaLang#40495

Fixes JuliaLang#52657

Make tuple construction from known constant-length iterators inferrable
and prevent allocation.

Fixes JuliaLang#52993

Compute more accurate tuple element types in many cases using
`typeintersect`, with a fallback to the old behavior. This prevents
some cases of `convert` throwing due to ambiguity.

Instead of just calling `typeintersect` on the tuple types, do
`typeintersect` again once `fieldtype` computes the element type.

Fixes JuliaLang#53181

Separate the tuple construction from tuple element conversion, allowing
dropping the `tuple_type_tail` dependency.

Fixes JuliaLang#53182
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
collections Data structures holding multiple items, e.g. sets
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

improve construction of <:Tuple types from iterators nsajko/julia
3 participants
@goretkin @nsajko @jakobnissen