Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request ".." operator to broadcast field access #32796

Open
lincolnhannah opened this issue Aug 5, 2019 · 6 comments
Open

Feature Request ".." operator to broadcast field access #32796

lincolnhannah opened this issue Aug 5, 2019 · 6 comments
Labels
domain:broadcast Applying a function over a collection kind:speculative Whether the change will be implemented is speculative

Comments

@lincolnhannah
Copy link

For class MyClass.MyMember
And ArrayofMyClass = [ Instance1, Instance2 ... ]

Can we have:
ArrayofMyClass..MyMember = [ Instance1.MyMember, Instance2.MyMember ... ]

Combining the standard "." for object member and Julia "." for vectorising an operator.

@mbauman
Copy link
Sponsor Member

mbauman commented Aug 5, 2019

We currently allow .. to be used as a user- or package-defined operator, which has led to its use in things like Interval arithmetic, EllipsisNotation, and more. So unfortunately changing this would be quite breaking. There's also a competing proposal in #20502 for nested broadcast.

I could have sworn we had an issue for this, but it looks like we just brought it up in the comments of #19169 (comment).

@mbauman mbauman changed the title Feature Request ".." operator (array of object members) Feature Request ".." operator to broadcast field access Aug 5, 2019
@mbauman mbauman added kind:breaking This change will break code domain:broadcast Applying a function over a collection kind:speculative Whether the change will be implemented is speculative and removed kind:breaking This change will break code labels Aug 5, 2019
@JeffBezanson
Copy link
Sponsor Member

Another idea is to have a clojure-ish synax (.a) meaning x -> x.a. But of course _.a is pretty much just as good.

@lincolnhannah
Copy link
Author

What about overloading the "." operator and just use x.a
ie, x.a = [x[1].a x[2].a .... ] if x is an array.

@mbauman
Copy link
Sponsor Member

mbauman commented Aug 6, 2019

Unfortunately, that's not possible because it's ambiguous if you're doing access on the array itself or its elements. Array itself doesn't have any Julia-accessible fields, but other arrays may. Here's a good example — ranges are arrays that have fields, and Dates are elements that have fields. In this case the names are distinct, but it's entirely possible that some other element type might happen to use the same field names.

julia> using Dates

julia> r = now():Day(1):now()+Day(2)
2019-08-06T12:58:14.878:1 day:2019-08-08T12:58:14.878

julia> r.start
2019-08-06T12:58:14.878

julia> r[1].instant
Dates.UTInstant{Millisecond}(63700779494878 milliseconds)

julia> map(x->x.instant, r)
3-element Array{Dates.UTInstant{Millisecond},1}:
 Dates.UTInstant{Millisecond}(63700779494878 milliseconds)
 Dates.UTInstant{Millisecond}(63700865894878 milliseconds)
 Dates.UTInstant{Millisecond}(63700952294878 milliseconds)

@StefanKarpinski
Copy link
Sponsor Member

It also just violates the general principle of "don't conflate scalar operations with their vectorized forms" which is the mess we originally inherited from slower languages that need to do that. Let's not make that mistake all over again.

@stevengj
Copy link
Member

With #24990 or similar, you could do (_.a).(myarray) or myarray .|> _.a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:broadcast Applying a function over a collection kind:speculative Whether the change will be implemented is speculative
Projects
None yet
Development

No branches or pull requests

5 participants