`Vec{N, T}` constructor should construct `Vec{N, T}` instance about meshes.jl HOT 7 CLOSED

I see your point now. It makes total sense to respect the type in that case. Appreciate if you can submit a PR that throws an error.

from meshes.jl.

Thank you for the fix!

from meshes.jl.

We opted for a continuous representation of coordinates, and designed these constructors to never allow discrete spaces (e.g. integers). Can you elaborate on why you need integer coordinates?

from meshes.jl.

Can you elaborate on why you need integer coordinates?

I actually don't have a practical application with integer coordinates. That was just a minimum example.

As I said in the title, the problem is the return type of the constructor. Most users definitely expect return type T if the users explicitly called T(x). (cf. related official documentation about parametric constructors)

We have two choices to resolve this issue.

• Make Vec{3,Int}(1,2,3) throws an error.
• Remove the restriction with floating point numbers.

Make Vec{3,Int}(1,2,3) throws an error.

This is the easiest way to resolve the issue. Just updating the L50-56 with:

 function Vec{Dim,T}(coords::Union{Tuple,AbstractVector}) where {Dim,T<:AbstractFloat}
   if Dim ≠ length(coords) 
     throw(DimensionMismatch("invalid dimension")) 
   end 
   Vec(NTuple{Dim,T}(coords)) 
 end 

Remove the restriction with floating point numbers.

I prefer this solution to the previous one.

• I initially called something like string.(Vec(1,2,3)) to export the values to a text file. Relaxing the constructor can avoid this kind of error.
• Vectors with integer elements are useful for Pick's theorem. I think supporting Vec{N, Int} is not that bad idea.
• There was a comment about the element type on discourse. (https://discourse.julialang.org/t/ann-announcing-meshes-jl/53973/38)
• Someone may want to use FixedPointNumbers.Fixed to represent the elements of a vector. This type is an example of a continuous representation of coordinates without floating point numbers.

from meshes.jl.

As I said in the title, the problem is the return type of the constructor. Most users definitely expect return type T if the users explicitly called T(x). (cf. related official documentation about parametric constructors)

On the other hand, we had multiple reports of users having trouble with geometric algorithms because they fed geometries with Integer coordinates. The algorithms assume continuous coordinates, and the errors were cryptic to end-users. That was a design decision that we made a long time ago to make sure that code written as Vec(1,2,3) still works.

This parameter T will be revisited soon anyways given the new CRS infrastructure.

from meshes.jl.

That was a design decision that we made a long time ago to make sure that code written as Vec(1,2,3) still works.

My point is, Vec{3, Int}(1,2,3) should be Vec{3, Int} or throw an error. Vec(1,2,3) isa Vec{3, Float64} is not problematic at all.

I opened a related PR JuliaLang/julia#53328 that updates the style guide.

from meshes.jl.

Resolved by #763

from meshes.jl.