[fpc-devel] "Default" discussion for SmartPointers etc
Michael Van Canneyt
michael at freepascal.org
Thu Jul 28 12:40:22 CEST 2016
On Thu, 28 Jul 2016, Sven Barth wrote:
> Am 27.07.2016 23:27 schrieb "Jonas Maebe" <jonas.maebe at elis.ugent.be>:
>> Before continuing, I think it would be a good idea to look at what the
> desired concept is exactly (transparent proxy objects/references, thin
> wrappers that allow to specify some default behaviour, nullable types, ...
> ?) already exists in other programming language (not C++ -- everything is
> just meta-programmed using templates there) and how things work there at
> least from a specification standpoint.
> The main features that Maciej wants to achieve - at least as far as I can
> see it - is ARC without changing TObject (basically the approach that one
> would choose in C++) and Nullable types.
> For the later I've found that C# and also Oxygene implement this, however
> they don't do this based on the type, but the variable.
> === code begin ===
> x: nullable Integer;
> === code end ===
> Pointer types (in Oxygene these are only object references, in FPC that
> would also include the managed strings and dynamic arrays) are inherently
> nullable ("nullable Pointer" or "nullable TObject" wouldn't be any
> different from regular "Pointer" and "TObject") this also introducing "non
> nullable", though I don't think we'd need this for now.
> I haven't checked in detail, but there is probably a check for Nil plus an
> exception if a Nil-nullable is assigned to a non-nullable variable
> (something like "as" basically).
> So we /could/ solve the Nullable topic by using the approach Oxygene has
> chosen, maybe only with an exception of var-parameters (as internally it
> would probably be represented by a automatically generated container
I don't see how you can solve nullable var parameters in native code.
There is no way you can detect a write to the address, necessary to set
the not-null flag.
So I would conclude that "nullable" support is incompatible with var params.
Assuming that is the case, the "default property in record" approach invented by
Izak seems IMHO more powerful than
x: nullable Integer;
If you consider that
X : TNullable<Integer>;
makes X a different type from 'integer', the fact that you cannot pass it in a var
parameter (expecting Integer) simply follows from the strict type checking rule of pascal.
I find that easier to explain than explaining that a non-nullable defined as
x: nullable Integer;
("which is after all an integer") cannot be used in var parameters.
More information about the fpc-devel