Post #2218779

2026-02-15 04:36 UTC

@jplatte@social.tchncs.de Do you think the default should actually be evaluated in a const context at build time (and then... cloned on every invocation)? Should it be a thunk that gets called at function call time? Something else? Does the answer change for const fn versus fn? What is in scope when it's evaluated?

Replies (2)

@jplatte@social.tchncs.de 2026-02-15 06:46

@roguelazer@hachyderm.io so, I actually was thinking after submitting that maybe there'd be more uses of non-const defaults for fn params than for field defaults (where the RFC was accepted with the same restriction). But if this were to be done with the restriction, I think it should work the same way, which I think is equivalent to supplying a named const or const block as the argument (maybe what you meant by cloning on every invocation, though the Clone trait is not involved).

Open ##2218780
@pointlessone@status.pointless.one 2026-02-15 09:03

@roguelazer@hachyderm.io @jplatte@social.tchncs.de Scope question is interesting. For example, in Ruby you can reference other arguments for default values: def example(arg1, arg2 = arg1) #… end Which roughly (not really) translates to the following: def example(arg1, arg2 = nil) arg2 ||= arg1 #… end

Open ##2218782