On Thu, 28 Jul 2016, Sven Barth wrote:
Am 27.07.2016 23:27 schrieb "Jonas Maebe" <jonas.ma...@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 ===
var
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
record).
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
var
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.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
