[Lazarus] Forward declare (modern) records [was: Re: "global" operator overloading]

[ListMember]

On 2013-02-26 17:18, Sven Barth wrote:
> On 26.02.2013 16:15, ListMember wrote:
>>
>>> All three types, records, objects and classes have their purposes and
>>> uses and one can select the one that is most fitting in a given
>>> situation.
>>
>> Is it possible to forward declare records the way we can with classes?
>>
>> I mean, with classes, I can do this:
>>
>> TSecondClass = class;
>>
>> TFirstClass = Class(TObject)
>> private
>>    FSecondClass: TSecondClass;
>> public
>> end;
>>
>> TSecondClass =  Class(TObject)
>> private
>>    FFirstClass: TFirstClass;
>> public
>> end;
>>
>> but, I don't seem to be able to do the same with records --I am
>> referring to the new/modern records.
>>
>> I can see why it isn't immediately available, but it would be so much
>> nicer if fpc handled the pointer stuff in the background.
>
> It would be no use anyway. You CAN NOT have the record used as a field 
> inside itself, so you'd need to define a pointer type anyway. And this 
> is something where we won't do things behind the programmers back. If 
> you need a pointer then you declare one.

Well.. yes and no.

Here is my use-case:

I am working (on and off) on string classes. I have basically 3 string 
types: TByteString, TWordString, TCardinalString string each 
representing a different char/codepage width/bytesize.

And, I'd like to have the user-facing interface to be somethig like this:

TByteString = record
{...}
public
   property AsWordString: TWordString read GetWordString write 
SetWordString;
   property AsCardinalString: TCardinalString read GetCardinalString 
write SetCardinalString;
end;

TWordString = record
{...}
public
   property AsByteString: TByteString read GetByteString write 
SetByteString;
   property AsCardinalString: TCardinalString read GetCardinalString 
write SetCardinalString;
end;

TCardinalString = record
{...}
public
   property AsByteString: TByteString read GetByteString write 
SetByteString;
   property AsWordString: TWordString read GetWordString write 
SetWordString;
end;

Having these properties would be very useful; but if I have to use 
pointers, then I believe it would force almost all the rest of the 
calling code to be based on pointers --defeating the purpose of 
simplicity for the user.