API request: a function to unwrap Val

[tkf]

This is either an API request or a documentation request. It'd be nice to have an API that does

f(::Val{x}) where x = x

If it already exists, it'd be nice to mention it in Val's docstring.

If it does not exist, maybe getindex or get would be a nice function for this? Or maybe add a new function?

This came up in JuliaArrays/StaticArrays.jl#702 (comment)

[DilumAluthge]

This makes sense to me.

Any suggestions for the name? unwrap?

[DilumAluthge]

I think getindex doesn’t really make sense because you can’t pass an index.

get would make sense.

[tkf]

My thought process was that Val is somewhat like Ref as they are both "something that wraps a single value":

julia> x = Ref(1);

julia> x[]
1

julia> y = Val(1);

julia> y[] # doesn't work now, but maybe it's OK if it does?

[DilumAluthge]

Ohhh I see what you mean.

Now that I’ve seen it written out, I actually kind of like that API.

[c42f]

Nice, thanks for making this issue! Out of those options I think I'd prefer getindex to get. The analogy to Ref seems reasonable and I can't think of any negative consequences right now.

[simeonschaub]

One thing to think about is whether it would be useful to allow unwrapping just the type of a value type, e.g. Val{1}, as well. Unfortunately, we can't use getindex here, as it already creates an empty array. If Val(1)[] works, users might then also intuitively think that Val{1}[] works the same way, and be really confused when it creates an empty array, so I don't know whether getindex is the right syntax for this.

[DilumAluthge]

One thing to think about is whether it would be useful to allow unwrapping just the type of a value type, e.g. Val{1}, as well. Unfortunately, we can't use getindex here, as it already creates an empty array. If Val(1)[] works, users might then also intuitively think that Val{1}[] works the same way, and be really confused when it creates an empty array, so I don't know whether getindex is the right syntax for this.

That’s a good point. Maybe a new function unwrap is best. It would accept both types and instances.

[mcabbott]

Perhaps the right function is only?

[rapus95]

One thing to think about is whether it would be useful to allow unwrapping just the type of a value type, e.g. Val{1}, as well. Unfortunately, we can't use getindex here, as it already creates an empty array. If Val(1)[] works, users might then also intuitively think that Val{1}[] works the same way, and be really confused when it creates an empty array, so I don't know whether getindex is the right syntax for this.

Would you expect Val{1}[] to create an array? Tbh I didn't. And I neither see a usecase for it as those types are singletons. So we might simply overload getindex for Val types to return the argument.
Base.getindex(::Type{Val{x}}) where x = x

EDIT: There are nevertheless good reasons against this, keep reading.

[rfourquet]

So we might simply overload getindex for Val types to return the argument.

No this is bad for predictability and general consistency. getindex on types is already a concession to the "a fonction has one meaning" rule. If there are exception to this concession, things get harder to understand. The more exceptions, the more difficult the language is to learn.

[rapus95]

Ah, main problem being

function fuse(x::T, n::Int) where T
  collected = T[]
  for i=1:n
    push!(collected, x+i)
  end
  return collected
end

style functions. Where arbitrary stuff could happen.

[rafaqz]

I just wanted this yesterday.

I like unwrap, because it would also be good to have:

t = Tuple{Int, String}
julia> unwrap(t)
(Int, String)

etc. I also find using getindex on types confusing.

[kmsquire]

As a point of reference, ResultTypes uses unwrap to get a value out of a Result. Conceptually, it's quite similar (although Results may also contain errors (Exceptions) instead.

(Adding this to Base would also require ResultTypes to import it and would break anything using ResultTypes.jl until that happens...)

[mcabbott]

If thinking of Val(3) as a container like Ref(3), then the tuple idea sounds more like eltype(Ref(3)) == Int than like Ref(3)[] == only(Ref(3)) == 3. Perhaps there should be a function like eltypes(Tuple{Int, String}) == (Int, String), but making eltype(Val(3)) return 3 would be weird.