markup

content/news/2023/10/06/deref.adoc

@@ -19,7 +19,7 @@ We've spent a ton of time over the last week looking at the internals of LazySeq
 
 Additionally, we continue to work on functional interface adapters and method thunks. With FI adapters, we continue to refine when implicit coercion and conversion occur and I think that continues to draw asymptotically closer to completion. With method thunks, we have taken a bit of a detour to examine array class representation.
 
-Generally, classes are represented by symbols that name the class, but this does not work for array classes as they cannot be represented as a valid symbol. The fallback right now is using a String that holds the internal class name, like ^"[Ljava.lang.String;" which I think we can all agree is no fun. Our plan going forward is to support a new array class syntax which is a symbol of the class with a `*` suffix. Imported classes can use their short name, so `String*` will represent a Java String[] (or a String... vararg). Multiple `**` will represent multidimensional arrays. This will work with both classes and with primitives, so `long*` will be a synonym for the existing `longs`. Rich also wishes you to notice the C pointer punnery. :)
+Generally, classes are represented by symbols that name the class, but this does not work for array classes as they cannot be represented as a valid symbol. The fallback right now is using a String that holds the internal class name, like `^"[Ljava.lang.String;"` which I think we can all agree is no fun. Our plan going forward is to support a new array class syntax which is a symbol of the class with a `pass:[*]` suffix. Imported classes can use their short name, so `pass:[String*]` will represent a Java `String[]` (or a `String...` vararg). Multiple `pass:[**]` will represent multidimensional arrays. This will work with both classes and with primitives, so `pass:[long*]` will be a synonym for the existing `longs`. Rich also wishes you to notice the C pointer punnery. :)
 
 That was a bit of a diversion, but I think it is a big win to fix a long-time representational gap. It also helps create some new "columns" in the varargs decision matrix, which is not going to be addressed in 1.12, but I think we have teed up to work on immediately after.