I think this has been mentioned before, but I haven’t been able to find follow up.\ \ len() used to return _undef_ without a complaint when fed a scalar or a value of _undef_, very nicely. I recently upgraded to the latest release, and now it spews warnings that are in my view irritating and utterly unnecessary.\ \ Are there plans to change that?

I believe the change is about 3 years old at this point so I'm pretty sure it's not going to change back. In my experience, the changes relating to undefs that were made mostly help with debugging by preventing undef values due to errors from propagating through the code, though there are occasional situations where the new behavior can be a little annoying. I think people used to check whether something was a list by computing its length and checking if it was undef. Now you do that with is_list(). It's tough to think of any other reasonable need to call len() on something that's not a list, though I vaguely recall that nophead had some use case for this. On Fri, Dec 2, 2022 at 3:32 PM <lionstone@mail.com> wrote: > I think this has been mentioned before, but I haven’t been able to find > follow up. > > len() used to return _undef_ without a complaint when fed a scalar or a > value of _undef_, very nicely. I recently upgraded to the latest release, > and now it spews warnings that are in my view irritating and utterly > unnecessary. > > Are there plans to change that? > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

I’ve been a lot happier anyway since I turned on Stop On First Warning. I haven’t had a need to change it since. -Bob Tucson AZ On Dec 2, 2022, at 15:28, Adrian Mariano <avm4@cornell.edu> wrote: I believe the change is about 3 years old at this point so I'm pretty sure it's not going to change back. In my experience, the changes relating to undefs that were made mostly help with debugging by preventing undef values due to errors from propagating through the code, though there are occasional situations where the new behavior can be a little annoying. I think people used to check whether something was a list by computing its length and checking if it was undef. Now you do that with is_list(). It's tough to think of any other reasonable need to call len() on something that's not a list, though I vaguely recall that nophead had some use case for this. On Fri, Dec 2, 2022 at 3:32 PM <lionstone@mail.com <mailto:lionstone@mail.com>> wrote: > I think this has been mentioned before, but I haven’t been able to find follow up. > > len() used to return _undef_ without a complaint when fed a scalar or a value of _undef_, very nicely. I recently upgraded to the latest release, and now it spews warnings that are in my view irritating and utterly unnecessary. > > Are there plans to change that? > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org <mailto:discuss-leave@lists.openscad.org> _______________________________________________ OpenSCAD mailing list To unsubscribe send an email to discuss-leave@lists.openscad.org

Before the changes in question, Stop on First Warning didn't help as much as you might think, because tons of undef operations gave no warning. You could do a computation that mistakenly had an undef in it, get an undef out, do arithmetic on it and the undef would just propagate through your code and the first warning wouldn't come until hundreds of lines of code later. I always run with Stop on First Warning. On Fri, Dec 2, 2022 at 5:56 PM Bob Carlson <bob@rjcarlson.com> wrote: > I’ve been a lot happier anyway since I turned on Stop On First Warning. I > haven’t had a need to change it since. > > -Bob > Tucson AZ > > > > On Dec 2, 2022, at 15:28, Adrian Mariano <avm4@cornell.edu> wrote: > > I believe the change is about 3 years old at this point so I'm pretty sure > it's not going to change back. In my experience, the changes relating to > undefs that were made mostly help with debugging by preventing undef values > due to errors from propagating through the code, though there are > occasional situations where the new behavior can be a little annoying. I > think people used to check whether something was a list by computing its > length and checking if it was undef. Now you do that with is_list(). It's > tough to think of any other reasonable need to call len() on something > that's not a list, though I vaguely recall that nophead had some use case > for this. > > On Fri, Dec 2, 2022 at 3:32 PM <lionstone@mail.com> wrote: > >> I think this has been mentioned before, but I haven’t been able to find >> follow up. >> >> len() used to return _undef_ without a complaint when fed a scalar or a >> value of _undef_, very nicely. I recently upgraded to the latest release, >> and now it spews warnings that are in my view irritating and utterly >> unnecessary. >> >> Are there plans to change that? >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

Len was documented as returning undef for a non list so it should never have been changed but was. It just made all my code longer and slower. On Fri, 2 Dec 2022 at 23:02, Adrian Mariano <avm4@cornell.edu> wrote: > Before the changes in question, Stop on First Warning didn't help as much > as you might think, because tons of undef operations gave no warning. You > could do a computation that mistakenly had an undef in it, get an undef > out, do arithmetic on it and the undef would just propagate through your > code and the first warning wouldn't come until hundreds of lines of code > later. I always run with Stop on First Warning. > > On Fri, Dec 2, 2022 at 5:56 PM Bob Carlson <bob@rjcarlson.com> wrote: > >> I’ve been a lot happier anyway since I turned on Stop On First Warning. I >> haven’t had a need to change it since. >> >> -Bob >> Tucson AZ >> >> >> >> On Dec 2, 2022, at 15:28, Adrian Mariano <avm4@cornell.edu> wrote: >> >> I believe the change is about 3 years old at this point so I'm pretty >> sure it's not going to change back. In my experience, the changes relating >> to undefs that were made mostly help with debugging by preventing undef >> values due to errors from propagating through the code, though there are >> occasional situations where the new behavior can be a little annoying. I >> think people used to check whether something was a list by computing its >> length and checking if it was undef. Now you do that with is_list(). It's >> tough to think of any other reasonable need to call len() on something >> that's not a list, though I vaguely recall that nophead had some use case >> for this. >> >> On Fri, Dec 2, 2022 at 3:32 PM <lionstone@mail.com> wrote: >> >>> I think this has been mentioned before, but I haven’t been able to find >>> follow up. >>> >>> len() used to return _undef_ without a complaint when fed a scalar or a >>> value of _undef_, very nicely. I recently upgraded to the latest release, >>> and now it spews warnings that are in my view irritating and utterly >>> unnecessary. >>> >>> Are there plans to change that? >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

There is some infrastructure for tracking where an "undef" came from, so that you can see the launch point rather than the impact point, but I don't think it's gotten very much love.