At 17:56 +0200 30/9/05, Frank Heckenbach wrote:
BTW, I see that Mac Pascal seems to have the address operator, so how does it behave actually, Peter? If foo is a MedInt, would @foo be compatible to a variable of type p1, p2, the parameter p, or what? Or compatible to any pointer type, i.e., @ returning an untyped pointer, like earlier BP verisons did (later ones had an option)?
@foo is equivalent to type Pointer, it's compatible with any pointer.
At 20:57 +0200 30/9/05, Frank Heckenbach wrote:
Actually, structural equivalence is IMHO the only sensible choice for array slices -- otherwise one gets too many spurious type errors.
Indeed, this could be a good solution for both problems. In BP mode (more precisely, in {$T+} mode -- thanks, Chief, for pointing out this fine point I wasn't aware of), all pointer types would be "unbranded". In default mode, explcit pointer types would be branded, but the result of @ would not (so, due to the rule above, it would be compatible with p1 and to p2, but p1 and p2 wouldn't be compatible with each other -- seems kind of sensible, perhaps that's also how Mac Pascal behaves?).
This sounds like a good solution. One thought too, if "unbranded" was an attribute, it might be useful for cases where you wanted to actively allow looser type checking than normal without having to set a looser mode in generally, perhaps something like:
type CFTypeRef = ^UInt32 atttribute( unbranded ); CFArrayRef = ^UInt32; CFStringRef = ^UInt32;
Now CFArrayRef and CFStringRef are incompatible, but both are compatible with the generic CFTypeRef....
Also, that could open the way for supporting univ in a relatively safe mode by saying:
procedure doit( p: univ MyType )
marks p as unbranded MyType
I'm not sure whether that would really be loose enoguh for univ (which is perhaps better as requiring a pointer type and matching as an untyped pointer), but it might be a safer solution that fits in well with this.
Anyway, just some thoughts.
Enjoy, Peter.