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."
BTW, this behavior apparently is undocumented, it's not in the guide nor
in the changelog.
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.
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? 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'.
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'.
cheers,
sven