Examples that come to mind are in compare functions for routines such as qsort and bsearch or any other routine that uses generic pointers. In those cases, the simplest, cleanest and correct solution is to "absolute" variable declarations with the proper type on top of the generic pointers. Without "absolute" every use of the generic pointer would require a typecast.
"absolute" is by far, the cleanest way of "dis-ambiguating" accesses to structures such as the optional header or the import thunks, those two among thousands of similar situations.
I'd like to see @PascalDragon comment on that. The core question is whether an untagged variant record can be used in this context, i.e. with the currently-assumed type indicated by a named field, or whether it /has/ to be done using absolute.
I have absolutely no idea how a untagged variant record would come into play here. For functions that take plain
Pointer parameters, but where you know the type of the pointer (e.g. the mentioned compare functions or a function that has some kind of context pointer parameter like e.g. in the compiler's
foreachnodestatic functions)
absolute is by far the easiest and quickest way to get the correct type (you can't check the type anyway here).
I know this would upset Sven, but since he's not risen to my request that he comment on the adequacy of untagged variant records in the context of generic pointers I presume he's skipping this thread.
I'm only skimming this thread, cause when I see
Warfley and
440bx throwing walls of text against each other I'll just throw out a “nope” and walk away.
But I frankly I'd be happier if the core language, even if it did have facilities for reference-counted managed entities etc., made no attempt to sugar the syntax; instead outside the core language have a tasty fleshy layer, with a trait-based inheritance system which was able to specify that e.g. "a reference of this type should be automagically dereferenced" as well as "this type of cast may be performed implicitly" etc. (both of those examples amount to "here's how to make type X compatible with type Y", and I think it's reasonable to teach a compiler that trick).
Feel free to start your own language then. With Object Pascal and Free Pascal this isn't going to happen.