Repository navigation
keyword argument constructor for immutables #5333
Description
Activity
I like this. If we're going to do something like this, could we also consider having both mutable and immutables types allow default values, which would allow the use of keyword arguments for construction from scratch (rather than based on a small variant of an existing immutable)? When writing my Vega wrapper I wound up writing up some hacky code to allow type fields to have default values and would love to have something more official.
Even better:
foo(x::foo; bar=x.bar, baz=x.baz) = new(bar, baz)Reacted by Azamat Berdyshev, Brandon H. Gomes and Elias CarvalhoReacted by Eric Forgy and Elias CarvalhoI really like that last version. The business with
nothingas a default feels icky. Any particular reason this only applies to immutables? I guess it's more useful with immutables since you can just copy and mutate a mutable object.- added a commit that references this issue
on Mar 12, 2014 Relatedly it might make sense to have nice to have syntax sugar for modifying the field of an immutable when placed in an array.
- added this to the milestone
on Aug 21, 2014 It would also be nice to not have to write down the type. In haskell it would be
x=foo(1,2); y=x{baz=3}In elm (haskell-like pure language):y={x | baz <- 3}(see elm records). Is it too confusing to havex.baz = 3translate tox = foo(x, baz=3)for immutables?Yes, we dislike that idea since it means
x.baz = 3may or may not be a mutating operation depending on the type ofx. That code will silently do subtly different things for different types ofx.- added 2 commits that reference this issue
on Sep 21, 2014 - added a commit that references this issue
on Dec 9, 2014 Relatedly it might make sense to have nice to have syntax sugar for modifying the field of an immutable when placed in an array.
@Keno, is there any work done in this direction?
I actually wrote some code to do this, basically offering one more dimension for setindex, for arrays of immutables (well in my case fixed size arrays)...
This is especially nice for editing color channels of images, when the color is an immutable.I think we need to start thinking about syntax for modifying immutables in place in arrays (and potentially in other mutables) now that that tuples can be used as fixed size arrays. Right now using them that way is quite painful.
Bump
- added a commit that references this issue
on Jun 28, 2015 2 remaining items
I think we still want this – at least I periodically do and then wonder why we don't have it yet.
Reacted by Damien Drix, Utkarsh Upadhyay, Valentin Churavy, John Myles White, Christopher Rackauckas, Patrick Kofod Mogensen, ylxdzsw, Oliver Schulz, Evan Patterson, Gustavo Goretkin and 6 moreI don't believe this would be breaking, would it?
Wouldn't it break
Adjoint?Base now has
@kwdef, which I guess pretty much replaces this, since we haven't had this for many releases now anyways
@JeffBezanson and I were discussing adding a second default constructor with the semantics
This would cover the case where you want to obtain a new value with one field changed e.g. in the example above
This is especially useful when the immutable has a lot of field. One example that comes to mind and where I already define a constructor like the above is URIParser.jl