[fpc-pascal] Name collisions in scoped enums
Sven Barth
pascaldragon at googlemail.com
Tue May 5 07:19:43 CEST 2020
Am 05.05.2020 um 04:16 schrieb Ryan Joseph via fpc-pascal:
>
>
>> On May 4, 2020, at 10:44 PM, Michael Van Canneyt <michael at freepascal.org> wrote:
>>
>> That is how enums work by default in Pascal.
>>
>> If you don't force scoped enums, you can still scope them.
>>
>> if you use
>> $scopedenums on then you simply force the use instead of having it optional.
> But the names collide then, that's the whole point. We want to protect against name collisions and we don't want to type long prefix names every time. Scoped enums fixes half of that by formalizing the prefix syntax but you still need to type it even when it could be inferred by context.
>
> Swift figured out how to do this and so should Pascal imo.
Surprise: Pascal is /not/ about writing less. Pascal is about writing
correct code.
Take this:
=== code begin ===
{$ScopedEnums On}
type
TTest = (
Value1,
Value2
);
TTests = set of TTest;
procedure Something(aArg: array of LongInt); begin end;
procedure Something(aArg: TTests); begin end;
var
Value1: LongInt;
begin
Something([Value1]);
end.
=== code end ===
Right now it's clear what procedure is called, namely the one with the
open array. If we'd allow scoped enums without their enum type then this
would result in a "can't decide which method to call". This example
might appear constructed, but imagine these to procedures coming from
two different, unrelated units.
But there is another reason why what you suggest is even /impossible/:
The parser does not know what is called until it has completely parsed
the call and then has done its overload solution. Thus it /can not/ find
a scoped enum value without its type name (such enum values are not
visible in the unit's symtable after all!). And the compiler is not
allowed to just pick a function and hope for the best as that might lead
to the wrong one (think about the example above or one where you have
two different enums with the same value).
Regards,
Sven
More information about the fpc-pascal
mailing list