You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
uniment opened this issue
Feb 10, 2023
· 4 comments
Labels
arrays[a, r, r, a, y, s]designDesign of APIs or of the language itselfduplicateIndicates similar issues or pull requestsfeatureIndicates new feature / enhancement requests
y =Array{Float64}(i+j for i=1:m, j=1:n)
y == Float64[i+j for i=1:m, j=1:n] # true
Would passing generators to the Array constructor be redundant with comprehensions? Yes. Why request it then? Because a) it'd create consistency with the fact that other similar constructors also accept generators (e.g. Tuple, NamedTuple, Dict, etc.), and b) it creates an idiom for non-standard arrays to be constructed with generators.
The text was updated successfully, but these errors were encountered:
I would hope to not limit this feature to only generators, but any iterators. It would also provide an idiomatic solution to #47777: Vector{Float64}(rand(2, 2)), or Vector(rand(2, 2)), is probably the most straigthforward way to say "give me a vector out of this matrix".
Yes, this is redundant with the definition of collect also, and also that yes we should finally implement this, as we already did for other constructors as you noted
arrays[a, r, r, a, y, s]designDesign of APIs or of the language itselfduplicateIndicates similar issues or pull requestsfeatureIndicates new feature / enhancement requests
(Related Discourse discussion)
This would be nice:
Would passing generators to the
Array
constructor be redundant with comprehensions? Yes. Why request it then? Because a) it'd create consistency with the fact that other similar constructors also accept generators (e.g.Tuple
,NamedTuple
,Dict
, etc.), and b) it creates an idiom for non-standard arrays to be constructed with generators.The text was updated successfully, but these errors were encountered: