Re: RFC: Support Closures in constant expressions

On Thu, Oct 31, 2024, at 15:12, Gina P. Banyard wrote: > On Thursday, 31 October 2024 at 07:22, Rob Landers <rob@bottled.codes> wrote: > >> To be honest, I thought it was a rhetorical question since the example is a runtime error >> (passing string to a function that takes an array), but on this note, we already know how it should >> behave: https://3v4l.org/RC6b3 because, as you said, it is captured >> by value. In theory, to support this, we would probably need “late binding constants” or >> constants that are executed just before any userland code is run. Similar to just emulating it >> yourself: https://3v4l.org/PMY4W >> >> IMHO, the rules around constant expressions are not sound and feel arbitrary when you run >> into them. They are too easy to work around (though cumbersome) and the code still works, which >> seems to prove their arbitrary nature. > > define() does not produce "true" constants and has always allowed to define constants > at run-time where there is more information available. > > const expressions have *always* been about determining and defining constants at compile time > so they can be put in SHM. > Which is why the const keyword exist. > (and yes I know define() expression that are const expression are "true compile time > constants") > > Best regards, > > Gina P. Banyard Hey Gina, I was mostly referring to the comment that we can't define the expected behavior, not necessarily what is a "true constant" or not. — Rob