I was thinking about my patch for default properties and how invasive the changes are into the compiler and heavy handed the approach is. I’m not even sure the compiler team would accept it like it is since it has such potential for overreach and having strange unpredictable effects.

In my opinion C++ has a more reasonable approach which does 95% of the things we actually need for the use cases (i.e. nullable types/ARC-like classes, like shared_ptr in C++). Their approach is to allow overriding the “postfix" operator (-> in C++ but “.” for classes in FPC) which is then used in conjunction with various other operator overloads (like := and =).

I think this solution is better because:

1) The changes in the compiler sources are maybe 10% of what they need to be with default properties.
2) The user can better manage access to the underlying class instead of hoisting up the entire namespace up for all possible circumstances. This approach gives the user much greater control overall.
3) The effects are very predictable, that is, you know it only affects the record when you use “.”. Default properties need to have wide-reaching effects in a multitude of different syntaxes.
4) It has the support of the C++ team and years of real world usage (std::shared_ptr etc…).

Does that make sense? I’d like to scratch the idea of default properties and do this instead if it was permitted.

========================

type
  TAuto<T> = record
    m_obj: T;
    // … other management operators …
    class operator postfix: T;
  end;
class operator TAuto.postfix: T;
begin
  result := m_obj;
end;
var
  a: TAuto<TObject>;
begin
  writeln(a.ClassName); // a.m_obj.ClassName

Regards,
Ryan Joseph

Ryan Joseph wrote

Does that make sense? I’d like to scratch the idea of default properties and do this instead if it was permitted.

No. FPC is not going down that operator madness.

Regards,
Sven

So why are default properties better? I thought the compiler team would like the idea of . overloads because it’s so much less intrusive on the compiler and more predictable for the user. Please explain your reasoning if you don’t mind.

Regards,
Ryan Joseph

Because I don't want to open the can of worms that is going to be overloading the postfix "operator". People are going to abuse the hell out of it (they will with default properties as well, don't get me wrong there), making the language much harder to read. Nowadays you can rely on the "." denoting some sub element. With operator overload using a "." could mean triggering some credit card payment (I'm exaggerating here, but this would technically be possible).
Default field properties extend a mechanism that already exists and also have a much narrower scope of possibilities for abuse.

Regards,
Sven

On Jun 7, 2019, at 4:56 PM, Sven Barth via fpc-devel wrote: Because I don't want to open the can of worms that is going to be overloading the postfix "operator". People are going to abuse the hell out of it (they will with default properties as well, don't get me wrong there), making the language much harder to read. Nowadays you can rely on the "." denoting some sub element. With operator overload using a "." could mean triggering some credit card payment (I'm exaggerating here, but this would technically be possible).

The default properties are a much bigger can of worms. That’s why I suggested the operator overload.

With default properties you can do this:

======

var
  rec: TMyRecord<TObject>; // assume TMyRecord has a default property to a field with TObject
begin
  // assignment operator overloads
  rec := TObject.Create;
  // classref access
  writeln(TMyRecord.ClassName);
  // all statements, with, while, if, for etc...
  with rec do
    ;
  while rec do
    ;
  // postfix, fields and function overloads
  rec.Free;
  // all binary AND unary overloads
  if rec = nil then
    ;
end.

=====

All the postfix operator allows is “.” access. That’s like 90% less intrusion into the compiler. Much smaller can of worms. Sorry C++ had the smarter idea here. Limit the access to “.” and if the user wants assignments or equality etc… they overload other operators. Please tell me how that’s a bigger can of worms.

Regards,
Ryan Joseph

Before we add a postfix operator I prefer not to add *any* of this *at all*.

Regards,
Sven

On Jun 7, 2019, at 5:08 PM, Sven Barth via fpc-devel wrote: Before we add a postfix operator I prefer not to add *any* of this *at all*.

What about smart pointers then? I don’t want Pascal to get left behind on this. We need a solution for this and I want it to be the least intrusive possible and I think C++ did the right thing. Keep in mind this is in retrospect after developing default properties (https://github.com/genericptr/freepascal/tree/defaultprops) albeit perhaps poorly, and seeing how intrusive the idea is compared to what C++ did.

Any other voices on this would be welcome.

Regards,
Ryan Joseph