[bug #68172] any() and all() should work only on numeric or logical args

Markus Mützel <[email protected]>
Newsgroups gmane.comp.gnu.octave.bugs
Message-ID <[email protected]>
Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only notification stream.  Info posted to this mailing list address won't appear in the tracker database where it is most useful.

Update of bug #68172 (group octave):

                  Status:         Patch Submitted => None

    _______________________________________________________

Follow-up Comment #9:

The default implementations of the `all` and `any` members of the
`octave_base_value` class returned false at least since 1996 (hg id
2142216bf85a).
Downstream implementations of classes that inherit from it might be relying on
that behavior. I'm not sure whether we should change that now. (At the very
least, we shouldn't change that in a minor release.)

Would it also be possible to override these functions in the implementation of
`octave_classdef` with something like the following (untested)?

octave_value
octave_classdef::all (int) const
{
  err_wrong_type_arg ("octave_classdef::all ()", type_name ());
}

octave_value
octave_classdef::any (int) const
{
  err_wrong_type_arg ("octave_classdef::any ()", type_name ());
}


And the equivalent for the `octave_struct` and `octave_cell` classes.

If that works, it wouldn't interfere with what downstream packages might
expect. And it might help to reduce the number of files that would need to be
changed in Octave itself.

On the other hand, `all` and `any` should really fail for anything that isn't
numeric or logical (e.g., function handles). So, the list of classes that
would need to be changed might be even longer than with your current patch.

If downstream octave_value classes actually want to work with the `all` or
`any` functions, they would probably need to override those functions anyway.


I'm tending towards applying your patch on the default branch (for Octave 12).


On the off-chance that downstream octave_value classes actually depend on the
current behavior, it might make sense to add a warning in
`octave_base_value::all` and `octave_base_value::any` on the stable branch
that will say that this is going to throw an error in Octave 12.
I don't think we necessarily need the typical deprecation period of two major
versions though (because the current behavior being used on purpose is
probably unlikely).

However we decide to proceed, this is probably worth a note in the NEWS file.

What do you think?



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68172>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc (application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCac/FqwAKCRCqLAuaBUf3
TioJAQDDR+4SlbjZTJa2FiFkMh6dG1Oy3+xwzTMmDP8D7MvqvAD+JGOrnqz30GRV
tNCrKY/oCjXyJD7ZhUOSCGaNTHFeWQI=
=rinq
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.