Hello, could someone talk about what the future plans are for this syntax in 0.7? It seems there is a very long discussion about it on github, but I don’t have time to dig through hundreds of posts.
It would be convenient if someone knowledgeable could concisely summarize what exactly the motivations and future intentions for this change were.
We’ve long supported constructing an Array with a set of known contents like Array(1:3) or Array(sprand(4,4,.4)). We want to generalize this to all iterables and all Abstract Array types, but the specifying-dimension-sizes-for-an-uninitialized-array is ambiguous: Is Array(2) constructing [2] or [#undef, #undef] (since numbers are iterable collections themselves)? Using an explicit initialization object allows us to disambiguate this case… and also support Array(3I, 5, 5) and maybe other clever yet-do-be-discovered things.
couldn’t something shorter be used, like Array{T}(new,2)?
uninitialized is a bit cumbersome.
/Paul S
I do agree that uninitialized is quite long and hard to type. That was why I was on team junk in the uninitialized versus junk wars.
Yea, I also don’t like the uninitialized, which is why I was wondering about it. A mouthful to type… couldn’t the unitialized option be the default? Oh, well…
How about free or malloc? Just a thinking.
Several of us have taken a shot at that one. It’s hard.