Re: [RFC] [VOTE] Transform exit() from a language construct into a standard function

On 30.07.2024 at 14:30, Gina P. Banyard wrote: > On Tuesday, 30 July 2024 at 13:47, Christoph M. Becker <cmbecker69@gmx.de> wrote: > >> Would that RFC imply that I would need to write \\exit or >> have a use exit clause to avoid dynamic namespace lookup? If so, I >> would be even >> less in favor of that change. > > No, since the new implementation where the token is preserved this is not needed. > You cannot define the function in a namespace, nor disable it, nor use it as a goto label. Okay, thanks for the clarification. > The one benefit of having it become a proper function which can also be used as a statement is: > - Using named arguments > - Passing it to callable parameters > - Usual type juggling semantics Personally, I'm not interested in doing the first two points. >> I do understand your point about the type juggling semantics, but I >> might have addressed that differently. I almost always use >> exit >> without argument (and if, only with an int), and die always >> with a >> string (and only for quick experiments), and I figure that this might be >> what most contemporary code does (at least, I hope that the >> do_something() or die() times have long gone). As such, >> having exit >> and die as alias could be changed, sticking with >> exit as a control >> flow instruction, and having die as proper function (which >> could even >> be implemented in userland), where exit would allow an optional int >> argument (like break), and die() a required string >> argument. Of >> course, this would be a much bigger BC break, but it seems to me the >> cleaner solution. > > This might be a good idea in the long term to properly split exit and die and have them take > only integers and string respectively, > but I am not going to personally bother with this, even if I think this is a good idea. Fair enough. Given that I'm very late to this party, and that I'm not strongly opposed to the suggested change, I will refrain from voting. Cheers, Christoph