Le mardi 08 mars 2016 à 16:08 +0100, Daniel Carrera a écrit : > > On 8 March 2016 at 15:52, Milan Bouchet-Valat <[email protected]> > wrote: > > > Array("hello") > > This case is tricky since Array{Int}(1) creates a vector with one > > element, not an array containing 1. So for consistency we have to raise > > an error for non-integer arguments. > > Array(1) fails, and Array{Int}(1) gives me 140180935446712 ??!!! > > julia> Array{Int}(1) > 1-element Array{Int64,1}: > 140180935446712 This is a one-element array with uninitialized memory. There's a discussion going on about whether to change this to return 0 or not: https://github.com/JuliaLang/julia/issues/9147
> > > String(10) > > String isn't a concrete type currently in Julia, that's the old name > > for AbstractString. But the plans is to move to a single string type, > > so this could work. I agree that it would be more logical than writing > > string() in small case as currently. > > Yeah. Since `string()` works, String() could just be made to do what > `string()` does today. > > Can you tell me about the plans to move to a single string type? Does > that mean that the proliferation of string types (AbstractString, > ASCIIString, UTF8String, etc) is going to end? See https://github.com/JuliaLang/julia/pull/14383 There should only remain String (concrete) and AbstractString in Base. Packages will still be able to provide custom string types. > > Lower-case functions have been deprecated as much as possible. See > > above about string vs. String. so I don't think we're going to add new > > ones. > Ok. What's the issue with lower-case functions? That they are redundant, inconsistent or both with those starting with an upper-case? Regards
