That's wonderful news, thanks a lot for this. I know .() is just syntactic
sugar, but to me it really feels intuitive and powerful. Thanks again,
Michael
On Thu, Aug 18, 2016 at 8:27 PM, Steven G. Johnson
wrote:
> (If you want dot calls to work with your own container
(If you want dot calls to work with your own container type, then you just
need to make broadcast(...) work. e.g. here is some discussion for
ApproxFun: https://github.com/ApproxFun/ApproxFun.jl/issues/356)
On Thursday, August 18, 2016 at 2:22:13 PM UTC-4, Michael Borregaard wrote:
>
> It'd be nice with a list of the methods a user-defined type would need to
> define to be amenable to .() in an Array.
>
In 0.6, once #16966 is ironed out, then you won't have to anything (as long
as you want your
It'd be nice with a list of the methods a user-defined type would need to
define to be amenable to .() in an Array.
On Thu, Aug 18, 2016 at 8:16 PM, Michael Krabbe Borregaard <
mkborrega...@gmail.com> wrote:
> Thanks! Right now it makes a difference for my understanding just to know
> that this
Thanks! Right now it makes a difference for my understanding just to know
that this is an issue with String, and that .() will otherwise behave like
map.
On Thursday, August 18, 2016 at 10:52:42 AM UTC-7, Michael Borregaard wrote:
>
> That sounds right. I wonder if this is not a bug?
>
>From my reading of the all the related issues, it is a known "issue" ;) It
looks like a good solution is being ironed out. But I don't think this will
be added
That sounds right. I wonder if this is not a bug?
My understanding (which can easily be wrong!) is that this stems from
https://github.com/JuliaLang/julia/issues/16966.
Namely that size("b") throws a method error, whereas your size(2) gives a
null tuple (). So in general broadcast (which is what the .() is sugar for)
requires that the element
Please ignore the erroneous first " in the last code line.