Panama source code fails to compile

[Maurizio Cimadamore]

On 05/01/2021 21:02, Ty Young wrote:
>
> The current API doesn't do that anyway, ofPaddingBits() returns a 
> MemoryLayout which is ambiguous in terms of implementation. Sure, in 
> most cases people just make as many ofPaddingBits() calls as needed 
> directly in a struct's layout so it doesn't matter, but if someone 
> were to hypothetically store the returned MemoryLayout in a variable 
> there would be no type information to indicate it was padding(this is 
> already true for MemoryLayouts padding constants, actually). Someone 
> could use a ValueLayout to pad the struct all the same.
>
>
> How about keeping PaddingLayout where it is, having ofPaddingLayout() 
> return PaddingLayout, and remove isPadding() for every layout type? 
> This way the type is clear and people can do instanceof and/or 
> getClass() themselves ? Would you accept a pull request for that?
>
This is what the code _used_ to do. After having a fruitful chat with 
Brian about an year ago, we ended up compressing the hierarchy, 
precisely to make it more friendly with pattern matching. I think that 
we will regret adding an extra subclass (which we'll be stuck with 
forever) when clients will have a much better way to test if a layout is 
padding or not. Of course the world right now is suboptimal, and methods 
like isStruct/isUnion/isPadding kind of make up for that. But the vision 
is clear: these methods are placeholder for better pattern match 
predicates, and will likely be deprecated at some point in the future 
(and I think you can agree that deprecating a predicate method is much 
less intrusive than deprecating PaddingLayout/StructLayout/UnionLayout). 
For the records, this is also why the layout API does not have a 
visitor-like mechanism.

As for the digression on whether we're breaking API principles and all 
that, I think pattern matching is a fact of life in Java (the first 
batch of work has been finalized in 16), and I'd rather design an API 
taking into account where the language might land, rather than design it 
in a silo. Of course you are right in that there's no guarantee on if 
and when later pattern matching features will show up - but if they do 
show up at some point (and I don't see why they shouldn't), I think we'd 
be sorry for having missed that train. And, if these feature do not make 
it, we're left with a bunch of predicates which, honestly, look pretty 
harmless to me.

Anyway, point noted.

Maurizio