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 type, then you just
> need
(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 t
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 i
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 t
Please ignore the erroneous first " in the last code line.