[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.


More information about the fpc-devel mailing list