I wrote a thing (Pre-RFC for the Rust programming language): https://internals.rust-lang.org/t/pre-rfc-function-parameter-defaults/24011/1
Remote
Jonas Platte
@jplatte@social.tchncs.de
mastodon 4.7.3they/them · born 1996 · living in Germany
☀️ Solarpunk
💜 Anti-Fascist
🧠 Probably autistic
🐧 Linux poweruser(ish)
⌨️ Software engineer (no AI!)
225 Followers
239 Following
10 Posts
Joined December 08, 2021
Blog:
Matrix (Chat):
Codeberg:
My GitHub feed be like ↓ 🤮
Not sure why I even went there. I'm sure it's just a matter of time before the next big wave of people leaving this ever more awful place, similar to what happened with Twitter.
Replying to
@elly@donotsta.re @sleepyowl@chaos.social @valpackett@social.treehouse.systems is money the hardest part? How much are we talking? The 3 extra ppl sounds like it should be easy? (I know ppl who probably care about this in at least Croatia + Denmark)
Replying to
@calisti@chaos.social not in scope because I think the proposal would be too big with both at once, and parameter defaults are useful on their own. I have a design in mind, but it's hard to find the time to actually write it down. When I do write it, it will go into interactions with param defaults.
Replying to
@pointlessone@status.pointless.one
Every major programming language package manager provides some sort of scaffold for a new project. All those scaffolds include a license and it’s some sort of FLOSS license.
I am happy to be able to correct you there. Rust's cargo does not add a LICENSE file or set the corresponding package metadata field when creating a new project with cargo new / cargo init.
Replying to
@pointlessone@status.pointless.one Absolutely, MIT and MIT OR Apache are very popular choices in the Rust community. I've defaulted to MPL-2.0 for a while which is a little less permissive. Have considered https://anticapitalist.software/ for new projects more recently. The Big Time Public License was new to me, but looks pretty decent as well. (you wrote "Bit Time", by the way)
Replying to
@roguelazer@hachyderm.io so, generic parameters of the function would be in scope, but nothing else that's not also in scope at the fn decl level. Nothing would be different whether the fn was const or not.
Replying to
@slatian can you share a minimally reproducible example of the Layer struct version that doesn't compile?
Replying to
@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).
Replying to
@pointlessone@status.pointless.one if you want to call it that, sure. I don't think Rust should ever support Java-style function overloading though.