On 30.07.2024 at 14:30, Gina P. Banyard wrote: > On Tuesday, 30 July 2024 at 13:47, Christoph M. Becker <cmbecke...@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
