The following code is compilable.
I'm using a private const with type defined and I can change it in the constructor.

1. Is this by design?
2. Is there a way to declare attributes "final" like Java does?

=== begin ===
type
  TFoo = class
  private
    const INT: Integer = 0;
  public
    constructor Create;
  end;
implementation
constructor TFoo.Create;
begin
  INT := 9;
end;
end.
=== end ===

Best regards,
Marcos Douglas

2017-07-30 18:37 GMT+02:00 Marcos Douglas B. Santos :

1. Is this by design?

Yes. To disallow this you need to use {$J-} directive.

2. Is there a way to declare attributes "final" like Java does?

No for constants.

I know that we can use this "hack" in local functions/methods, but in an attribute... What is the goal to use it?

I would like to instantiate my attribute only once inside constructor and then it will be "const" or "final", I mean, immutable. Today it is not possible, right? Any thoughts to the future?

Regards,
Marcos Douglas

Marcos Douglas B. Santos wrote

I would like to instantiate my attribute only once inside constructor and then it will be "const" or "final", I mean, immutable. Today it is not possible, right? Any thoughts to the future?

It is not what you are asking for, but you can do this:

===code begin===
{$J-}
const
   INT: Integer = 9;
type
   TFoo = class
   strict private
     function GetINT: Integer;
   public
     property INT: Integer read GetINT;
   end;
function TFoo.GetINT: Integer;
begin
   Exit(INT);
end;
===code end===

The INT property is 'immutable' because it is read-only, and you cannot assign to its typed integer referent because of the {$J-}.

$J affects all kinds of constants no matter whether they are global, inside a routine or inside a type. Though it seems that this is broken as the compiler allows an assignment nevertheless... *sigh*

With the JVM platform support for final fields was added (modeswitch finalfields), but that is currently only available for external classes (which only exist for the JVM target) as the DFA can't handle that correctly currently.
(though if one would restrict the assignments to the constructors itself without any methods called by the constructor then we might be able to implement that nevertheless, don't know what Java or other languages with final fields allow here)

Regards,
Sven

It would be great to use "modeswitch finalfields" in all possible modes.

Regards,
Marcos Douglas

Sven Barth wrote

(though if one would restrict the assignments to the constructors itself without any methods called by the constructor then we might be able to implement that nevertheless, don't know what Java or other languages with final fields allow here)

Java final fields can only be set in constructors (and only once in each constructor, but I guess it isn't necessary to immitate this part).

But that is the goal to achieve...
Not because Java, but to restrict the initialization of the attributes.

Regards,
Marcos Douglas

Marcos Douglas B. Santos wrote

But that is the goal to achieve... Not because Java, but to restrict the initialization of the attributes.

I meant that if its trivial to restrict setting final fields to constructors, but it might be a lot of work to check and make sure that in each possible execution path inside the constructor the field can only be set once, I would be happy to have a final implementation which doesn't do this detail.

Understood.
The main goal is having final fields, not matter whether they need to be initialized only in constructor or not.
I agree (for the first version).

Best regards,
Marcos Douglas