Feature request: hard type creation/declaration

[Martin_fr]

Then again, simply don't use the record types in release builds. If you checked a debug/test build, and it compiled, then your types are ok. That doesn't change if your release doesn't use the records.

And if you do (should work too)

Code: Pascal  [Select][+][-]

1. type
2.   TNEW = record v : ptruint; end;
3.   TFoo = type TNew;
4.  

then its only one line to be changed. All others will change automatically.

[440bx]

It is completely irrelevant that base types are assignment compatible among each other.

What's needed is a way to tell the compiler that a type definition is NOT compatible with other types that use the same base type, so that an HWND cannot be assigned to an HPALETTE and so on.

It must not take tens of lines of various compiler construct to accomplish something so simple.

The importance of this feature is that it prevents errors without the programmer having to bend over backwards and stand on one leg to create code that MAY prevent that error while opening the door to many more because of the complexity associated with implementing this fairly simple feature (at the compiler level.)

Using records doesn't work.  It's like offering a tricycle as a replacement for seat belts.  Granted, it's very unlikely that someone on a tricycle is going to reach dangerous speeds but, way too much is lost in that "implementation".

[Martin_fr]

What's needed is a way to tell the compiler that a type definition is NOT compatible with other types that use the same base type, so that an HWND cannot be assigned to an HPALETTE and so on.

The below is not meant as a bias no the request (I don't mind if or if not...) assuming a good definition can solve this.
But technically, it might pose an issue.


If you make
  HWND incompatible, then it would also be incompatible with ptrUInt. It would have to be, otherwise if HWND and HPalette are both compatible to PtrUint, then they are compatible to each other.

So then what happens to
  if   MyHwnd <> 0  then
?

That would stop working too. (and what if zero is a int variable, because it may be 0 or -1 ?  / and that var should compare to HWND and HPALETTE ?)

You need a whole new set of rules when types are sometimes compatible.
Well, yes the operator overloads do that, because fpc only inserts a single operator at max. So it can be done technically.

Not sure what other quirks may need to be addressed.

----
I even have code of my own, where I would like the compiler to do such verifications.

But since I haven't got a good answer to the potentially needed rule set... I don't currently ask for it. (Again, don't mind if/that you do / then I don't need to answer those things)

[440bx]

If you make
  HWND incompatible, then it would also be incompatible with ptrUInt. It would have to be, otherwise if HWND and HPalette are both compatible to PtrUint, then they are compatible to each other.

So then what happens to
  if   MyHwnd <> 0  then
?

That would stop working too. (and what if zero is a int variable, because it may be 0 or -1 ?  / and that var should compare to HWND and HPALETTE ?)

You got it right.  an HWND should be incompatible with everything except another HWND.  In the example, "if MyHwnd <> 0 then..." the compiler should summarily reject that.  The correct statement is: "if MyHwnd <> HWND(0) then..." and that is presuming the underlying type of HWND is an integer type (as it would be in this case.) 

The compiler already has a _limited_ implementation of that concept when using enumerated types.  if you've got some variable of type TMYENUM, to assign an integer to that variable requires typecasting the integer, i.e, TMYENUM(42) or whatever other value is the one of interest.

[Martin_fr]

Actually, have you tried to make HWND an enum? with {$MINENUMSIZE xxx}  ?

Again, not trying to stop your request.
Just, trying to see if there is some immediately usable way.

And yes, any immedicable useable way will obviously a work around. If its good depends on how bad you want/need it.

[440bx]

Actually, have you tried to make HWND an enum? with {$MINENUMSIZE xxx}  ?

Again, not trying to stop your request.
Just, trying to see if there is some immediately usable way.

And yes, any immedicable useable way will obviously a work around. If its good depends on how bad you want/need it.

I tried all kinds of things, enums among them.  IIRC, with enums the problem is the enumeration range which is obviously limited to whatever is declared, that causes an interminable stream of warnings about values being out of range.

Currently, the problem has no clean solution.  There are ways to partially implement the feature but, every implementation using current facilities extorts a high price that makes it too cumbersome to use.

Implementing this feature in the compiler is fairly simple.  It only requires fairly minor changes in the scanner and parser.  None in later phases.

[Martin_fr]

You got it right.  an HWND should be incompatible with everything except another HWND.  In the example, "if MyHwnd <> 0 then..." the compiler should summarily reject that.  The correct statement is: "if MyHwnd <> HWND(0) then..." and that is presuming the underlying type of HWND is an integer type (as it would be in this case.) 

Ok, in that case, for your case there could be simple rules.

Then unfortunately for me, I would still not have a solution. My case requires that I can do math with the stored numbers.

Basically I have numbers that act as position or index. Historically (over many hundred thousands of lines) they are some 0-based some 1-based.

So, I don't want direct assignment (because then it points to the wrong item).
But I do need
  val := val + offs;

or even
  val_0 := val_1 - 1; // ok that should go through  a converter function


Which ultimately means, you actually don't want me to join your feature request, because my extra needs make it more complicated, and less likely to go anywhere.

[Martin_fr]

Well yes as I said workaround will be workarounds. 

If you want them depends on how bad/soon you need it. If you can wait until such a feature is released (if it ever is...), well then forget workarounds.

And yes, enums wont do. They are limited to 4 byte. So no PtrUint on 64bit.

The range checks could have been solved (within signed int range):

Code: Pascal  [Select][+][-]

1. {$MinEnumSize 4}
2. type
3.   TFoo = (e1=low(integer), e2=high(integer));
4.  

[440bx]

Actually, I think this feature request would work wonders for you...

consider this:

Code: Pascal  [Select][+][-]

1.  
2. type
3.   TRANGE0 = 0..high(ptruint);
4.   TRANGE1 = 1..high(ptruint);
5.  
6. var
7.   r0      : TRANGE0 = 0;
8.   r1      : TRANGE1 = 1;
9.  
10. begin
11.   r0 := r1;
12.   r1 := r0;
13.  
14.   r0 := 2 * r0 + 3;
15.   r1 := 3 * r1 + 5;
16.  
17. end.
18.  

what's needed is for TRANGE0 and TRANGE1 _not_ be assignment compatible which this feature request would do.

However, I believe that making them incompatible would also make them incompatible with any integer which would be a problem for you BUT, you can typecast the variable to its underlying type which would allow you to do math with it.

The only way you'd be able to assign r0 to r1 would be to typecast either one to the type of the other which you obviously won't do since that's what you don't want.

IOW, this feature would serve you very well.

[Warfley]

It is completely irrelevant that base types are assignment compatible among each other.

What's needed is a way to tell the compiler that a type definition is NOT compatible with other types that use the same base type, so that an HWND cannot be assigned to an HPALETTE and so on.

There is no basetype in Pascal, the Pascal typesystem is not based around magic base types from which others are derived (like for example C is), the typesystem of Pascal is based around number ranges and sets. What you are asking is not just a simple change, you request a fundamental change to the typesystem of Pascal.

Ordinal types in Pascal are not really types, they are defined as value ranges. Types in Pascal are from a theoretical level just a set of values. You can restrict the value set through subranges, so you can say Byte is a strict Subset of Word, this does not mean that Word is the base type of Byte or vice versa. They are just Sets.

As it is worded in the ISO 7815 Standard for Pascal:

A simple-type shall determine an ordered set of values . A value of an ordinal-type shall have an integer ordinal number ; the ordering relationship between any two such values of one type shall be the same as that between their ordinal numbers .

Integer, Word, Byte, etc. are all just subsets of the whole number range (and Double, Float and Real subsets of the Real numbers). Pascal does not have a concept of derived types for ordinals.

Don't get me wrong, I do like the idea of being able to create new distinct types, I'm just saying that this is something that the Pascal typesystem does not forsee at all and would be a very fundamental change to the typesystem, introducing a completely new kind of type (a derived type) to the language

[440bx]

@Warfley,

Do you ever have something actually useful to the topic ? or you have some uncontrollable need to pretend you know way more than you actually do ?

but, anyway, thank you so much for exposing the obvious and trivial... we all needed that.

[Martin_fr]

Actually, I think this feature request would work wonders for you...

However, I believe that making them incompatible would also make them incompatible with any integer which would be a problem for you

Your entire example however has the compatible...

BUT, you can typecast the variable to its underlying type which would allow you to do math with it.

And that would be any better than other workarounds? Huge chunks of code would be obfuscated. To be honest my operator overloaded record approach will give me better readability.

Of course, I could skip the records, and just create operators for those types that are now by themself incompatible.
But the gain would really be little for me.

Anyway, I am fine as it is now.
My problem isn't the missing feature (as I would be happy with my record approach). My problem is that its a massive amount of code, and thousands of variable declarations need to be checked and changed. That just is a massive amount of work. (no matter how the type gets made distinct)

[Martin_fr]

exposing the obvious and trivial... we all needed that.

I wasn't actually aware of it (as in having though about it). So I found it interesting info. Getting me to think a tiny moment about how it may differ for different language definitions.

[ASerge]

I think that if this feature is implemented, then later the code will immediately be littered with a bunch of type conversions that will only worsen the readability and clarity of the code.

[Warfley]

@Warfley,

Do you ever have something actually useful to the topic ? or you have some uncontrollable need to pretend you know way more than you actually do ?

but, anyway, thank you so much for exposing the obvious and trivial... we all needed that.

I answered something very specific you said:

It must not take tens of lines of various compiler construct to accomplish something so simple.

And I said that it does require introduction of a new kind of type, because the current ordinal types are designed to be compatible. Note not just assignment compatible as you claim, they are fully compatible.

This thing that you want does not yet exist as a concept in the language. So what would it take to include it in the compiler? First it requires the introduction of a new type kind, which in the fpc source is introduction of a new TDef including all the serialization and de-serialization into the PPUs.
Then this must be included in the typechecker, introduction of type conversions etc. Not to mention that when you introduce a completely new concept to the compiler you must verify that it works with the other features of the compiler as well. Like ordinals can be used for set slices, array indices, case labels, etc. Those all need to be extended for the new kind of type thats introduced.

When doing a simple text search for "orddef" which is the type identifier for ordinal types in the fpc sources, I get 2309 results. Which all need to be checked an many of those need to be amended for handling the new type.

Thats going to be more than "tens of lines". It's a very deep change to the whole compiler infrastructure

There would be a quick and dirty solution though, it could generate a dummy record type, and automatically generate the explicit cast operators for that type. But at that point you can also just define your own record types like Martin pointed out, which works perfectly well.