On Fri, 2016-06-17 at 18:19, Jacob Quinn <quinn.jac...@gmail.com> wrote: > There's been a long-open issue for this here: > https://github.com/JuliaLang/julia/pull/6122 > > Not sure why it's never been implemented as I don't think anyone was really > opposed. I imagine if people make a big push for it, we could convince > someone to get it across the finish line.
Check out https://github.com/mauro3/Parameters.jl . It makes keyword constructors as well as default values and other goodies. > -Jacob > > On Fri, Jun 17, 2016 at 11:17 AM, Stephan Buchert <stephanb...@gmail.com> > wrote: > >> When making instances of my composite Julia types, such as >> >> foo = Foo(1, "bartxt", 3.14) >> >> I often have to look up the definition, because I don't remember whether, >> in this case, "bar" was the first or the second field: >> >> type Foo >> bar::AbstractString >> baz::Int >> qux::Float64 >> end >> >> "bar" was the first field, so the correct construction is >> >> foo = Foo("bartxt", 1, 3.14) >> >> In this case the first, incorrect code would not compile because of no >> matching method. >> >> But for >> >> type Goo >> vertical::Float64 >> horizontal::Float64 >> qux::Float64 >> end >> >> it is easy to write incorrect code when the order of the fields gets mixed >> up, and such bugs are potentially difficult to find. >> >> Wouldn't it be possible to allow (optionally) for a syntax like >> >> foo = Foo(;bar=bartxt, baz=1, qux=3.14); >> goo = Goo(;horizontal=186.,vertical=0.33, qux=3.14) >> >> where the keyword arguments are the fieldnames of the type? >> >> Often I remember the fields of a type, but not their order. >> With this syntax the argument order would be arbitrary. >> The syntax would imply, that incorrect, non-existing, or missing >> fields/keywords result in an error. >> >> Thanks for your consideration. >>
