> > There should only remain String (concrete) and AbstractString in Base.
One string to rule them all... [image: Inline image 1] On Tue, Mar 8, 2016 at 10:14 AM, Milan Bouchet-Valat <[email protected]> wrote: > 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 >
