[fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements
Jonas Maebe
jonas at freepascal.org
Sun May 12 17:45:12 CEST 2019
On 12/05/2019 17:14, Ondrej Pokorny wrote:
> On 12.05.2019 16:36, Jonas Maebe wrote:
>> Thanks. I have added these warnings to the compiler in r42047, and
>> also the static/dynamic errors for Standard resp. Extended ISO Pascal.
>
> Very nice.
>
> One question about "C-style enumeration types"
> https://www.freepascal.org/docs-html/ref/refse12.html#QQ2-26-31
>
> Do the holes between undefined enum values belong to the enumeration or
> not? Because:
>
> 1.) The FPC documentation states they do not. See
> https://www.freepascal.org/docs-html/ref/refse12.html#QQ2-26-31
> /"The Pred and Succ functions cannot be used on this kind of enumeration
> types. Trying to do this anyhow will result in a compiler error."/
It's because Pred and Succ do not make sense with enumerations with
holes in our opinion, and could be confusing. E.g. in your example, one
could expect at first sight that succ(one) = two.
> 2.) The Delphi documentation states they do. See
> http://docwiki.embarcadero.com/RADStudio/Rio/en/Simple_Types_(Delphi)#Enumerated_Types_with_Explicitly_Assigned_Ordinality
> /"An enumerated type is, in effect, a subrange whose lowest and highest
> values correspond to the lowest and highest ordinalities of the
> constants in the declaration."/
>
> 3.) Your newly added warnings indicate they do.
I simply forgot to take them into account. I'm tempted to disable the
warning altogether for them, because
1) Semantically, it would make sense to give a warning only if not all
explicitly defined enum values are covered
2) However, you still can't give an "unreachable code" warning if
there's an "else" in that case, because implicit values can also be
stored in the enum
That would make the warnings inconsistent.
Jonas
More information about the fpc-devel
mailing list