| You still have not got it right. This is an old class of problem, documented since the 1960s. It's nothing to do with types. It's nothing to do with what language one uses (since it has been documented in languages as diverse as RPG and Pascal). It's the use of unexplained constant literals. M. Poettering was in fact doing the right thing and correcting the problem, replacing the unexplained constant literals written by M. Sievers ("mode > 0") with named constants ("mode != MODE_INVALID"). It is an example of the problem, one of whose symptoms is the question "Well which of these is the specific constant and which just happens to also be that number?", that M. Poettering missed a "mode > 0" that also needed replacing. Make no mistake. M. Poettering was actually applying the long-time well-understood fix for this. Here's Ted Holt talking about unexplained constant literals in RPG 4: * https://www.itjungle.com/2004/08/18/fhg081804-story01/ This same problem, and the approach of turning unexplained literals into named constants to improve maintainability, is explained all over the place, from William Allan Wulf's Fundamental structures of computer science published in 1983, through Niklaus Wirth in the 1975 Proceedings of the IEEE Conference on Reliable Software and Clark and Horning in a SIGPLAN paper in September 1973, to several of Gary Cornell's books on QuickBASIC and Visual BASIC in the 1990s. This is not a new thing, not language-specific, (clearly!) not addressed by changing language, nor addressed by types. |
(1) Where ints (or some other enumerable value unrelated to the problem domain) are used in place of self-describing enumerations because of lack of type system support for enums.
(2) When values within the domain of a type but outside of the domain that would otherwise be generated are used to signal special situations because of lack of type system support for sum types.
(The main other place that they occur is with "breakpoints" within a domain of a normal type, but even these are arguably a workaround for the absence of the combination of sum types and range-constrained types.)