ProductDomain should be more consistent

[dlfivefifty]

I would expect these both to be SVector{2,Int}:

julia> DomainSets.ProductDomain(0..1, 2..3) |> eltype
StaticArrays.SArray{Tuple{2},Int64,1,2}

julia> DomainSets.ProductDomain(0..1, [2,3]) |> eltype # Why Tuple?
Tuple{Int64,Int64}

[daanhb]

The second case seems to trigger this fallback: https://github.com/JuliaApproximation/DomainSets.jl/blob/659b385f4020034ef3ca264e0f53cfd9dfc5e71a/src/generic/productdomain.jl#L48

Tuples are the default because it is the only safe choice. The reason the fallback is triggered is that [2,3] is not (yet) recognized as a Domain, it is only converted to a WrappedDomain later by the TupleProductDomain constructor. A solution may be to write instead:

ProductDomain(domains...) = _ProductDomain(map(Domain, domains)...)
_ProductDomain(domains...) = TupleProductDomain(domains...)
_ProductDomain(domains::VcatDomainElement...) = VcatDomain(domains...)

?

Perhaps conversion to a wrapped domain can also be avoided, but that is what currently happens anyway. An alternative may be to improve the logic of the ProductDomain constructor a bit and make it more robust.

[dlfivefifty]

I don't really need this yet so no rush, but perhaps when it comes up I can have a go and remove the need for WrappedDomain by making Domain and "interface".

[daanhb]

Meanwhile I checked and the "fix" above seems to work at least for the example you gave.

More generally, Domain is largely an interface already but not everywhere. In this case, for future reference, there are at least two issues here:

• I've often used convert(Domain{T}, d) as a generic way to ensure that the domain d actually has element type T, for example if the user has specified a T type in some concrete domain constructor. If d is not a Domain, this is where it ends up being wrapped (perhaps needlessly). However, it would be odd if convert(Domain{T}, d) returns something that is not actually a subtype of Domain, so we may want to use a different syntax for this purpose, so that an Array{T} can remain an Array{T}. And perhaps so that an Array{S} is converted to an Array{T}.
• The VcatDomain assumes that the member domains have a dimension. It can then figure out how to efficiently go back and forth between static vectors and the elements of the member domains with the right size (e.g. (1,2,2) for a product of a univariate and two 2D-domains into a 5D VcatDomain.) The logic of the dimension function needs to be expanded somewhat to deal with non-Domain arguments, perhaps by looking at the eltype. Perhaps the name is too generic for that purpose.

So for these two reasons it is currently not possible to avoid the wrapping of the array.