Separation between MemorySegment and MemoryScope

[Maurizio Cimadamore]

> I was more advocating for no default than trying to steer the default to come back to confined by default.
>
> For ByteBuffer, and it's true for MemorySegment too, if it's mapped in memory, it's not a reasonable choice to use a cleaner
> (I have stopped teaching mapped files in Java, it's done in another course in Rust because with a mapped file you will want to remap it / de-allocate it soon after explaining how it works).
>
> That's why i say that i don't think that a sane default exists and having no default is IMO a saner choice
> mostly because you force your user to ask themself what kind of scope should be used for that particular case.

> Also I don't believe that a lot of people will use MemorySegment, very like ByteBuffer, you only need a MemorySegment when you start to do lower level things,
> at that point having a behavior by default is a problem because you are hiding things under the carpet (we don't have to go too far to see this kind of bad defaults, the ByteOrder in ByteBuffer is one).

I think in a lot of these issues the answer is "it depends..."

I think the Panama elephant is rather big, and there is a tendency to 
see different parts of it, and convince that a single part is all there is.


But let's back away from assumption on whether people will use implicit 
allocation or not, I think what you really want to talk about here is 
whether, given a method like:

makeMeASegment(ResourceScope)

we should also have an overload:

makeMeASegment()


We chose to add it as an hat tip to the ByteBuffer API, so that users 
could gently progress towards the full complexity of managing lifecycles 
in the Panama API.

The core of what you say, really is: if you really want that, just do:

makeMeASegment(ResourceScope.defaultScope())

(where "makeMeASegment" is any method in the API that takes a scope) - 
and that's not much more complex to explain.


That's an option, of course - I'm not ruling that out. But I don't buy 
the argument that "nobody will ever be interested in the default we 
have" (since it still seems to me like an handy starting point).

There's also an hidden point in here: Maurizio, after all you're giving 
me pretty basic building blocks - this is no high-level API - why are we 
worried about devs learning about scopes? Which is probably also fair.

The flip of all that is that if ResourceScope was always required, you 
might have explicit deallocation in cases that don't really need it 
(e.g. create a segment once and stash it in a field) - and I think that 
cases like those are probably more common that we'd led to think by 
looking at JBS/SO.

Maurizio