On 11/07/2019 13:07, Michael Van Canneyt wrote:
There is no "disagreement". just doubt as to what the right approach is.
If the compiler assumes that an enumerated always contains a valid value,
then the logical consequence is that the above "is" always evaluates to
true. In that case it makes
On Thu, 11 Jul 2019, J. Gareth Moreton wrote:
On 11/07/2019 11:52, Ondrej Pokorny wrote:
BTW, your note in the issue report is very misleading:
https://bugs.freepascal.org/view.php?id=33603#c117162.
> The idea behind "is" and "as" is that they are the sole exception to
the rule and will
On 11/07/2019 11:52, Ondrej Pokorny wrote:
BTW, your note in the issue report is very misleading:
https://bugs.freepascal.org/view.php?id=33603#c117162.
> The idea behind "is" and "as" is that they are the sole exception to
the rule and will return False and raise an error respectively if the
On 11.07.2019 11:58, J. Gareth Moreton wrote:
Done!
Thank you for your work!
BTW, your note in the issue report is very misleading:
https://bugs.freepascal.org/view.php?id=33603#c117162.
> The idea behind "is" and "as" is that they are the sole exception to
the rule and will return False
Done!
On 11/07/2019 07:51, Michael Van Canneyt wrote:
On Thu, 11 Jul 2019, J. Gareth Moreton wrote:
Should I modify the patch to allow enumerations with holes with "is"
and "as"? Note that these operators will return True/not raise an
error if a value falls within a hole but is otherwise
On Thu, 11 Jul 2019, J. Gareth Moreton wrote:
Should I modify the patch to allow enumerations with holes with "is" and
"as"? Note that these operators will return True/not raise an error if a
value falls within a hole but is otherwise between the lowest and highest
elements.
IMO, yes.
Should I modify the patch to allow enumerations with holes with "is" and
"as"? Note that these operators will return True/not raise an error if
a value falls within a hole but is otherwise between the lowest and
highest elements.
Gareth aka. Kit
On 09/07/2019 20:19, J. Gareth Moreton wrote:
