Am 24.03.20 um 08:29 schrieb Sven Schreiber:
Am 24.03.2020 um 07:15 schrieb Artur Tarassow:
Am 24.03.20 um 02:09 schrieb Riccardo (Jack) Lucchetti:
On Mon, 23 Mar 2020, Allin Cottrell wrote:

I'm thinking that an early 2020b release would be good, to address
the macOS Catalina security issue (about which we'll probably hear

If possible I'd like the Windows build issue re-addressed. I'll report
back in the other thread about it today.

Here are my second thoughts. Usually when we offer a function version
of a command it's just a matter of adding convenience, for users
comfortable with function calls, with no change in semantics relative
to the command. That's true of the first version of funcerr() but not
the latest one. So my latest change is kinda unruly.

Well, anybody who uses funcerr must write her own function in the first
place, so not sure whether the usual rules for people "comfortable" with
calls apply. But personally I'm pretty much indifferent.

BTW, for me the funcerr() thing wasn't so much about saving a line of
code, but about the readability of the code. When you have to pre-create
the error message in a string, it is less clear whether that new string
variable has a more general meaning and scope beyond the funcerr
statement. When the message is directly wrapped inside the funcerr()
call, it is clear it is only that and nothing else.

Not sure "iferror" is an appropriate name for it. To me, it suggests
that if an error occurs do something else.

I guess I share Artur's interpretation.

I think this is cleaner. Eventually, we can deprecate the function
form of funcerr() and retire it (clearly, in due course).

I agree that this is much cleaner without the risk of breaking legacy code.

funcerr() is very new, you were the only one using it in a package as
Allin found out.

I would be fine of getting rid of it ;-)

Gretl-devel mailing list --
To unsubscribe send an email to

Reply via email to