Type check on type aliases
lazarus / 64-FPC development

----------------------------------------------------------------------
gidesa · 2024-01-24 12:00

Hello,
I have this situation, with a type alias of integer:

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i type 
MyInteger = type integer;  // note the "type" before "integer"var  mi:
MyInteger;  i: integer;begin  mi:=i;end; As says the manual, MyInteger
internally results as a different type from integer.
But the compiler accept the assignment without any error or warning.
Is possible instead to generate an error?
With that definition the programmer wants explicitly a new type, not a
simple alias of integer.
All checks during compilation time are a great aid, in my opinion. And
in this case FPC compiler could be
almost ready to add this check.
Thanks

----------------------------------------------------------------------
cdbc · 2024-01-24 13:35

Hi
I think it's because they're value compatible, it is also possible to
assign a word to a byte, just beware of the possible funny/wrong
result 
Regards Benny

----------------------------------------------------------------------
alpine · 2024-01-24 14:10

Wrap it in a record:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i type 
MyInteger = record    I: Integer;  end;   // Overload operators as
needed   operator +(A,B: MyInteger) C: MyInteger;  begin    C.I := A.I
+ B.I;  end;

----------------------------------------------------------------------
Thaddy · 2024-01-24 14:30

The specialized types are assignment compatible, but you can check if
the types are equal.

----------------------------------------------------------------------
gidesa · 2024-01-24 14:32

Yes, I could use records, and I have tried in other cases.
And sure, at run time I can check types and more.
But it not resolve the issue of having checks at compile time, in my
opinion is much better.
For example, a numeric type record with run time controls (Delphi
syntax):

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i // integer
bounded to 1-10 rangetype  integer1b10 = record  strict private   
num: Integer;  public    class operator Implicit(const N: integer):
integer1b10;     { Other operator as:    class operator Implicit(const
N: integer1b10): integer;    class operator LessThan(N: integer1b10;
I: integer): Boolean;    class operator Add(N: integer1b10; I:
integer): integer1b10;    class operator Inc(N: integer1b10) :
integer1b10;    ................    }  end; class operator
integer1b10.Implicit(const N: integer): integer1b10;begin  if (1<=N)
and (N<=10) then    Result.num:=N  else    raise
EOverflow.Create('integer1b10: out of 1-10 bounds');end;      var 
i10: integer1b10; begin  i10:=20;  // no warning/error at compile
time; generate exception at run timeend;

----------------------------------------------------------------------
alpine · 2024-01-24 14:39

You asked for an assignment-incompatible type. You can't assign
integer to it (compile time) unless you overload the assignment
operator.

----------------------------------------------------------------------
gidesa · 2024-01-24 14:42

In the integer1b10 example, the assignment operator (from integer) is
overloaded.
It's the class operator Implicit.
But no check at compile time.

----------------------------------------------------------------------
Thaddy · 2024-01-24 14:49

Quote from: gidesa on January 24, 2024, 03:32:43 pmYes, I could use
records, and I have tried in other cases.Why? That is silly. type 1 is
not equal to type 1 type 1 anyway.

----------------------------------------------------------------------
alpine · 2024-01-24 14:54

Quote from: gidesa on January 24, 2024, 03:42:54 pmIn the integer1b10
example, the assignment operator (from integer) is overloaded.
It's the class operator Implicit.
But no check at compile time. 
Then do not overload Implicit(). Can you paraphrase the original
question, please?

----------------------------------------------------------------------
Joanna · 2024-01-24 15:11

I’m not sure what the purpose of trying to create a new type of
integer would be. Of course a type of integer would be an integer. 
This reminds me of ctk...

----------------------------------------------------------------------
gidesa · 2024-01-24 15:37

Briefly, from FPC reference guide:

Quote"
3.8  Type aliases
-------------------

............

Type
MyInteger = Type Integer;
This not only creates a new name to refer to the Integer type, but
actually creates a new type. That
is, two variables:
Var
A : MyInteger;
B : Integer;
Will not have the same type from the point of view of the compiler.
However, these two types will
be assignment compatible. That means that an assignment
A:=B;
will work.
The difference can be seen when examining type information:
    If TypeInfo(MyInteger)<>TypeInfo(Integer) then
                        Writeln('MyInteger and Integer are different
types');
"

My question: would be possible, modifying the compiler, to have a
warning or error AT COMPILE TIME, instead that the silent assigment
compatibility? Maybe with a compiler option/switch.
As Joanna and Thaddy observe,  why to simply assign an alias to an
integer (and, indeed, to every other type, native or user) ? The
manual well explains situations where this is useful.
Maybe FPC developers do not plan to add this compile check. Whatever
is the answer, FPC remains a great compiler for me.
Thanks

----------------------------------------------------------------------
Joanna · 2024-01-24 15:41

I don’t think they will change it, this has been thoroughly discussed
on a previous occasion