Release notes are not feature frozen until the release. If there’s something that needs release notes or docs, we should add those.
A.ref.mem
Are you saying this is supported? Given that the ref field isn’t documented AFAIK, I’d think that even A.ref is not a valid thing to do for users who expect compatibility.
1 Like
I’m fairly sure that the backing Memory is internal also and even the fact that it’s backed my Memory is an implementation detail. Especially for Array{<:Any,1}, since the Memory may be reallocated. So once you’re asking for it, you’re already beyond the public interface.
Although there may still be value in a internal function for this purpose. I don’t know. A.ref.mem seems simple enough and, if it ever breaks in some future version, it will probably break loudly (so you’ll notice it and it will be easy to fix). Whereas an accessor function, even an internal one, carries some implication of forward support.
1 Like
My question was triggered by @mbauman 's suggestion that package developers may choose to use Memory, for example as the field of a custom type, if they do not need the full Array functionality (in particular the resizing property), but simply a block of memory of fixed size. Memory is definitely exported from Base, so its mere existence cannot be considered an internal implementation detail.
Actually, the documentation I am looking for is for the reverse operation. If I now want to return a normal Array which is constructed from (part of) a Memory object, what is the interface for doing so. Should I go via Base.unsafe_wrap using a pointer to my memory object, or can I directly create the Array from a MemoryRef?
julia> m = Memory{Int}(undef, 1)
1-element Memory{Int64}:
0
julia> a = @view m[1:1]
1-element Vector{Int64}:
0
julia> a.ref.mem === m
true
Thanks. That is convenient indeed. Somehow I missed that.
While playing around, I also noticed that some behaviour from the Julep is not working, for example:
a = Memory{Float64}(undef, 100)
ref1 = Base.memoryref(a, 10) # error
# but the following indirect approach:
ref2 = Base.memoryref(a) # works fine
ref3 = Base.memoryref(ref2, 10) # works fine
1 Like
It’s funny, I was trying to dissuade folks from using Memory.
But we’re in Internals & Design here — so discussions are especially blurry between internals and general usage. Memory is a new thing — and it replaces a bit of very deep magic with something that, yes, I do expect folks will start using more. But as you noticed, the docs are still nascent and can be improved. YMMV.
3 Likes