[fpc-devel] "Default" discussion for SmartPointers etc

[Michael Van Canneyt]

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 ===
>
> 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.