On Thu, 8 Mar 2018, Sven Schreiber wrote:
Am 08.03.2018 um 22:07 schrieb Allin Cottrell:
> On Thu, 8 Mar 2018, Sven Schreiber wrote:
>> but when I discovered that 'if strstr("what",
"ever")' worked
>> the same, I switched over to this shorter formulation some time
>> ago.
Well, let's not rewrite history: We discussed this in August 2016
(thread "Suggestion for new string-checking built-in function").
You said: "...allowed empty and non-empty strings to evaluate as 0
and 1 where the context requires a Boolean result", and then: "Now
enabled (at essentially zero cost). It can easily be reversed if
we find anything amiss with this behaviour."
Thanks for retrieving the history!
BTW, this behavior apparently is undocumented, it's not in the
guide nor in the changelog.
No, it seems to be in limbo.
> Since a release is imminent I think it's better to go with
fixing
> up what we have, at least for now.
Hm, or for the release maybe just leave things as they are, and
postponing the final decision? The problem with this fixing "for
now" is that it gets harder and harder to revert, if that's what
the plan becomes.
> Actually I'm quite happy with the strstr() case,
Well, what is actually the use case of this string portion that
strstr returns? I think I only ever use it for a string-find
check.
There are plenty of use cases for the return value from strstr
(extracting relevant substrings, carving up a string into
components). But I agree, quite often one simply wants to check if a
given string contains something or other. And in that context, just
using strstr as giving a boolean value, as in C, is a nice shortcut.
> It's the 'if "a"' case that makes me a bit
uneasy, but maybe I
> should just get over it!
No, I understand, and it could have far-reaching and difficult
consequences. For example, what exactly is a boolean context in
hansl, where there's no special truth value like TRUE or FALSE?
Well, wait a minute. "TRUE" and "FALSE" are pure synactic sugar for
non-zero and zero, at least in all the languages I have used to any
extent. The fact that we don't offer that sugar is not all that
relevant.
Strictly speaking that would mean I could claim to rewrite
'mwrite(m, fname, 1)' as 'mwrite(m, fname, "yep put it in the
dotdir")', since a non-empty string would be considered 'true'.
True in the limit, I suppose. Though that wouldn't work at present
and I wouldn't wish to make it work.
If we had some shorter syntactic sugar for
'strlen(strstr(...))'
(or almost equivalently 'strstr(...) != ""' we all could be happy
I guess. Back in 2016 I suggested 'strfind'.
Maybe. Personally, it just rankles a bit to define a new function
that returns a "collapsed" variant of what an existing function
already returns. But perhaps that's just me.
Allin