[fpc-devel] Re: Testing for..in feature

[Alexander Klenin]

On Fri, Nov 6, 2009 at 05:51, "Vinzent Höfler"
<JeLlyFish.software at gmx.net> wrote:
> Von: Michael Van Canneyt <michael at freepascal.org>:
>
>> Like I said, we should not have named it enums. They are not enums.
>> They're a hack to support some C construct in a type-safe way.
>> No more, no less.
>
> IBTD.

[skip Ada sample]

> They might be an ugly hack, but I really doubt the part about being a C construct. And then, even in Ada, the definitions have to be in (ascending) order. Which means, the compiler only has to support "holes", not an arbitrary set of values.
>
> Maybe this would be an option for FPC, too?

I agree that there is, in principle, nothing wrong with sparse enums.
However, Ada is well-known for sacrificing performance for correctness and
generality, and I am not sure if FPC should follow that.
The best Succ(X) algorithm I can think of that works correctly on
sparse enums is O(log enum_size).

>Which means, the compiler only has to support "holes", not an arbitrary set of values.

Yes, current enum implementation in FPC is slightly broken in this aspect:
---
type
  T = (a = 0, b = 0);
begin
  Writeln(b);
end.
---
Prints 'a'.

-- 
Alexander S. Klenin