the `Tuple`-`Tuple` constructor and the `convert` method may return an object not of requested type about julia HOT 8 OPEN

from julia.

I believe (but you can try testing this) taht the design and implementation of NamedTuple required that there was no type-assert here, as it relies on Type{T} elements being ignored. But there is not really a bug with it returning a value when it could have errored, and certainly not a correctness issue.

from julia.

Could you explain a bit more why the current behavior is correct? I'd usually expect that a call like T(x) or convert(T, x) would return a value of type T (or throw), which doesn't happen in this case.

I'm interested in this problem because I'm looking into fixing #52993, so there I hit the exact same problem of what to do with UnionAll types which subtype Tuple. I think that maybe we could just throw if the type is UnionAll?

from julia.

Some users want to write convert(Tuple{Type{T}}, (T,)). That is somewhat badly written, but actually fairly reasonable to want to work. I don't see how that is related to the performance of the current implementation for _totuple(::Type{Tuple{Vararg{E}}}, itr, s...). And we cannot just start adding breaking errors in v1.x for cases that are not previously broken.

from julia.

I notice that the behavior when constructing a tuple from a tuple is inconsistent with the behavior when constructing a tuple from other iterators (xref #44179, where it was concluded that a type assertion is desirable):

julia> NTuple{2}((1, nothing))
(1, nothing)

julia> NTuple{2}([1, nothing])
ERROR: TypeError: in typeassert, expected Tuple{T, T} where T, got a value of type Tuple{Int64, Nothing}
Stacktrace:
 [1] _totuple
   @ ./tuple.jl:474 [inlined]
 [2] (Tuple{T, T} where T)(itr::Vector{Union{Nothing, Int64}})
   @ Base ./tuple.jl:455
 [3] top-level scope
   @ REPL[4]:1

julia> versioninfo()
Julia Version 1.11.0-DEV.1451
Commit f117a500ca9 (2024-02-01 15:38 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 8 × AMD Ryzen 3 5300U with Radeon Graphics
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, znver2)
Threads: 1 default, 0 interactive, 1 GC (on 8 virtual cores)

I hope we could even out this inconsistency, in either direction?

from julia.

Would it be OK if we made the <:Tuple constructors always assert the return type, but leave convert as it is?

from julia.

Probably not. The inverse is possibly okay: convert already uses type-assert afterwards so would probably be unimpacted, but NamedTuple and similar codes already assume the constructor does not type-assert

from julia.

And to be clear, a type-assert would probably be welcome for both, but needs to be done such that it doesn't break other code

from julia.