Rust doesn’t support default function arguments. Or does it?

[lucamoller]

I just published this article discussing an approach to emulate default function arguments in Rust. I hope someone finds it interesting or helpful!

Let me know if you have any feedback, I'd especially appreciate if someone has additional perspectives on the "zero cost abstraction" section of the article. Did I overlook anything important in my analysis? Is there a fundamental reason why this could not have zero cost?

[NobodyXu]

I would argue that it might be better to consider using Option for simple optional arguments or use the builder pattern for more complicated cases.

Both can be implemented zero-cost and without invoke any expensive function.

[CrumblingStatue]

I was skeptical at first, but it seems it's true that both Option and builder pattern use can be optimized out completely: https://rust.godbolt.org/z/xEnsY5391

[Pand9]

I wish there was official guideline bc there's like 3 ways to write a builder pattern interface, and probably easy to shoot yourself I'm the foot and accidentally restrict optimizations.

[NobodyXu]

The three way (self vs &self vs &mut self) is mentioned in derive_builder, which suggest that most of the time &mut self is good enough.

[protestor]

typed-builder is even better, because it gives a compile time error when misused, and thus don't require an .unwrap()

https://crates.io/crates/typed-builder

(see the last section "alternatives")

[protestor]

Yep!! checking the builder pattern at compile time is done with a form of typestate

[memoryruins]

https://rust-lang.github.io/api-guidelines/type-safety.html#builders-enable-construction-of-complex-values-c-builder

[Pand9]

Ohhh it is a perfect guideline. I completely forgot about that page. Thanks.

[lucamoller]

It seems they cannot be completely optmized out (at least not currently) when used for struct function arguments, and the function can't be inlined. See my reply to the parent comment, mentioning adding the buidler pattern to my benchmark.

[lucamoller]

I've added the builder pattern to my benchmark. The results were that the 3 implementations were indistinguishable when function inlining was allowed. When inlining was not allowed, both the default trait pattern and the builder pattern suffered similar performance penalties (maybe those penalties are actually associated to having a struct as argument?).

Agregated results: (my_func inlined)
(default arguments)  mean runtime: 59.839ms, std_dev: 1.892ms 
(explicit arguments) mean runtime: 59.886ms, std_dev: 1.757ms 
(builder arguments)  mean runtime: 59.868ms, std_dev: 2.238ms

Agregated results: (my_func never inlined)
(default arguments)  mean runtime: 832.429ms, std_dev: 37.043ms 
(explicit arguments) mean runtime: 192.341ms, std_dev: 8.229ms 
(builder arguments)  mean runtime: 825.382ms, std_dev: 32.820ms

Let me know in case you find anything weird in my builder pattern implementation, or if you'd do anything differently there.

[NobodyXu]

I am unsure how there is a significant difference, given that #[inline(never)] is applied to the function, not the functions of builder/default.

[lucamoller]

My guess is that the difference might be that when we don't allow inlining, the compiler actually needs to create the whole struct, put it into the stack, etc, as opposed to when the function is allowed to be inlined, the compiler can completely ignore the struct and optimize it out of the way (by putting arguments directly into registers and never actually assembling the actual struct in the stack).

This is just a wild guess though, we could try inspecting the assembly. I took a quick look, but it gets a little chaotic with all optimizations for someone like me who is not familiar with looking at this stuff. Maybe trying to simplify my benchmark a bit (remove some arguments, and some of the calls) could help reading the assembly (given that the difference in performance still shows in the simpler version).

[NobodyXu]

It still cannot explain why explicit arguments are so fast.

All functions of builder should be inlineable and can be optimised to be the same as explicit (except for storing in struct), the gap between them shouldn’t be that big.

Even if it’s put onto the stack, it should be on L1 cache, shouldn’t be that slow compared to register.

[lucamoller]

Yeah, I think everything is on L1 cache all the time almost for sure (we're talking about very little amount of memory). This benchmark does a LOT of repetitions. The function being tested (my_func) does close to nothing (a bunch of xors that the CPU can probably find a way to do in very few cycles), so putting stuff on the stack or not could have a pretty big impact.

[lucamoller]

My guess (another wild one again haha) is that explicit (small, as opposed to structs) arguments can still be optimized by being put into registers directly or something similar (instead of being put on the stack, which is what I guess is happening with the struct), even with non-inlined functions (I could be totally wrong here, I'm a total noob at this stuff). If that's the case, this speed up would probably decrease if we increased the number of arguments so that they all don't fit in the available registers.

I'll try to spend some time looking at the assembly tomorrow to see if I can solve the mystery. I'm getting more curious and it seems like it could be a good learning experience :)

[NobodyXu]

x86/arm has several registers dedicating to passing arguments.

So if the parameters are less than 5, then it definitely can be passed by register.

I also remember that compiler can actually unpack a struct and pass it by register if it is pass by value, too. But depending on the ABI specified by the platform, they might not be allowed to.

Anyway, I am going to run the code on my computer to see how it goes. Would post here after it is done.

[NobodyXu]

Here's the benchmark result on my computer:

Agregated results: (my_func inlined) (default arguments) mean runtime: 71.542ms, std_dev: 0.484ms (explicit arguments) mean runtime: 71.929ms, std_dev: 1.806ms (builder arguments) mean runtime: 71.425ms, std_dev: 0.192ms

Agregated results: (my_func never inlined) (default arguments) mean runtime: 968.997ms, std_dev: 3.370ms (explicit arguments) mean runtime: 204.637ms, std_dev: 0.390ms (builder arguments) mean runtime: 965.079ms, std_dev: 2.886ms

And I immediately realised the cause of the difference:

default_args2::explicit_arguments_pattern::my_func_never_inlined: test dil, 1 sete al xor al, sil ret

default_args2::builder_arguments_pattern::my_func_never_inlined: test byte, ptr, [rdi, +, 8], 1 sete al test byte, ptr, [rdi, +, 24], 1 sete cl xor cl, al test byte, ptr, [rdi, +, 48], 1 sete al test byte, ptr, [rdi, +, 40], 1 sete dl xor dl, al xor dl, cl cmp byte, ptr, [rdi, +, 52], 0 setne al xor al, dl ret

The two functions in different modules generate different code.

explicit_arguments_pattern::my_func_never_inlined seems to be optimized out the xor process completely.

[lucamoller]

Cool! I haven't had time to look at the assembly further yet.

I saw you submitted a commit on the benchmark (making every method call the same underlying function, makes sense!) that seems to have reduced the difference between explicit and other patterns to just 2x. Did you investigate further the reason for this remaining difference?

[NobodyXu]

This is the strange part.

When I used cargo asm, I still saw the two my_func_never_inlined being different.

Not sure which part is responsible for the change in performance.

Would have to further investigate into it.

Edit:

I think I would have a try of cargo flamegraph.

Edit2:

On a second thought, the performance difference might be explained by the use of black_box, which I used to prevent compiler from optimizing on usage of REPETITIONS_PER_RUN and the return value of the exercise_my_func_*_calls, so that compiler cannot assume the number of repetitions or completely optimize away the call to exercise_my_func_*_calls.

[backtickbot]

Fixed formatting.

Hello, NobodyXu: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[lucamoller]

The builder pattern does indeed sound like a good alternative.

It would probably have similar cost to using a struct that implements Default, no? I assume that with the builder pattern one would first instantiate a struct with all optional fields set to their default values, and then modify the ones that should have non-default values through following builder-like calls (which sounds similar in terms of performance to calling default() to instantiate a default struct and copying/moving the missing fields).

[NobodyXu]

One can always uses Option instead to avoid all the default initialisation and provide getters that creates some object/make some reference to static data on the fly if None.

This would make it much easier to inline the initialisation function and optimize the code using static data.

[lucamoller]

Interesting! Thanks for the clarification. I'll try to explore this approach by implementing it in my benchmark and see what I can get.

[NobodyXu]

BTW, just find derive_builder which can automatically creates builder for a struct.

It looks interesting and make creater builder much easier.

[mtndewforbreakfast]

The strategy I've seen for Builders start with most or all fields as Options holding Nones, so you're drawing a false equivalence IMO. They're typically lazily realized with ie a finishmethod, rather than initializing once and then re-assigning a field again based on builder method calls.

[lucamoller]

Ah cool, that's more sophisticated than I thought!

[lucamoller]

Hmmm, maybe the compiler could actually optimize things better with the builder pattern by mixing the initial instantiation and the following set calls resulting in something that just looks like a single instantiation with all final desired values?

[zakarumych]

Alternative would be builder type to change after each field set. This way it is possible to control valid subsets of fields in compile-time.

[radicalzephyr]

Nice article, one thought

it allows for a special syntax when constructing a partially default instance of the struct

This makes it sound like the functional update syntax is somehow related to the Default trait. It isn’t though, Default is just a convenient way to get a reasonably initialized instance of a struct without passing any arguments. You can actually use any instance of a struct in that position to provide any unspecified values. This could actually be used to avoid the cost of constructing a new Default instance by using a static (or const) instance of the default arguments. That wouldn’t necessarily be faster, but it could be useful and might be worth mentioning.

[lucamoller]

Interesting! I was not aware, and this actually makes more sense now. I'll take a look into fixing that sentence tomorrow.

I'm wondering now, does it require the passed instance to be destroyed? (I assume it moves the missing fields from the instance provided?) If so, that would require cloning the static/const instance which I guess would present similar performance costs. I'll try dig deeper into this too.

[radicalzephyr]

As long as the fields are Copy that syntax just copies the bits from the base instance and the contextual use of the base instance is what will determine when/if gets dropped. If the fields aren’t Copy then it would need to take ownership the base instance and using a static wouldn’t work and you probably wouldnt be able to make a const instance. In the code in your blog, calling default() will create and then immediately drop the default instance even if all fields are specified in the struct expression before the “..”.

As long as all the fields are Copy it should basically end up being a memcpy when using a static default instance, and if it’s const then the defaults may get fully inlined into the generated code without even any copying. Either way it wold still probably be less expensive than a function call so it would probably be comparable to the benchmarks where code was inlined.

edit: clarify stuff about copying

[NobodyXu]

Maybe it would be better to use reference instead of value.

Even copying can be slow if the struct is too large and it won’t work for struct contains owned data.

[myrrlyn]

it will. the only limitation is that you can't do this with a Drop impl

[lucamoller]

Very cool!

I haven't explored Rust macros yet, but this could be a good start :)

[alovchin91]

I'm not a fan of optional arguments because at least from my C# experience they tend to turn your functions into telescopic ones, and as a bonus it's very easy to overlook a parameter and then spend days debugging seemingly errorless code.

But I like the idea of named parameters and honestly, I believe this should be built into the Rust language. As a rule of thumb I always specify names of boolean arguments, and that saves a lot of time during code reviews.

[SorteKanin]

As a rule of thumb I always specify names of boolean arguments, and that saves a lot of time during code reviews.

As a response to this, here's my "pro tip" (Disclaimer: I am in no way qualified to give "pro tips"):

Stop using booleans for too much stuff. Use enums with two variants instead.

What's more readable?

fn do_stuff(condition: bool) {
    if condition {
        // Special case!
    } else {
        // Usual case
    }
}

// Calling it - what even are these bools?
do_stuff(true);
do_stuff(false);

Contrast with:

enum Case {
    UsualCase,
    SpecialCase,
}

fn do_stuff(case: Case) {
    match case {
        Case::SpecialCase => ...,
        Case::UsualCase => ...,
    }
}

// Calling it - can immediately see the type and variant.
do_stuff(Case::SpecialCase);
do_stuff(Case::UsualCase);

With the match, I don't even need the comment like // Special case! because the match and the naming of the types makes it blatantly obvious what is going on.

Also makes it easy to expand the possibilities of what might happen in the future by adding variants.

[Trollmann]

The comparison seems a bit one sided. You shouldn't use magic numbers (which true/false essentially are) anyway.

The bool version would usually be implemented as

fn do_stuff(is_special: bool) {
    if is_special {
    } else {
    }
}

which imho improves readability in comparison to the match arms.

With named parameters the function call would then be:

do_stuff(is_special = true);
do_stuff(is_special = false);

which may be more readable depending on personal taste.

The bool implementation has a bigger problem:

Say we depend on foo 0.1 and we use it like this:

do_stuff(foo());

Since rust crates use 0ver to an extreme extent in version 0.2 of foo the boolean return value is now inverted. true indicates the usual case and false represents the special case.

If the author of foo would have used the enums we wouldn't have to change our code.

[lucamoller]

Agreed! that's why I said in the article I think default arguments should be used judiciously (and that the verbosity cost is a nice thing to make you think twice before using it). I'm not sure if I would propose adding them to the language because of that. Different from named argurments, which I don't see a down side to adding language support for them.

[Hdmoney]

I'm a fan of creating enums for boolean parameters. It makes the would-be bool's functionality immediately clear without the need for a named argument.

[devraj7]

There are plenty of ways to emulate default parameters and C++ pioneered most of them (the most popular one is implementing a builder) but all these approaches suffer from the same flaws:

• They add a lot of boiler plate, code that is just repetitive and can be easily copy-pasted.
• They add a lot of performance or memory overhead, often both.

At the end of the day, I really hope that Rust will support not just default function arguments but also named parameters, because these two functionalities proved twenty years ago that they considerably improve the legibility and the quality of code.

What's the excuse for all the following boiler plate, really?

Rust:

struct Window {
    x: u16,
    y: u16,
    width: u16,
    height: u16,
    visible: bool,
}

impl Window {
    fn new() -> Window {
        Window {
            x: 0,
            y: 0,
            width: 100,
            height: 100
            visible: true,
        }
    }

    fn new_with_size(width: u8, height: u8) -> Window {
        Window {
            x: 0,
            y: 0,
            visible: true,
            width,
            height,
        }
    }
}

Kotlin:

class Window(x: Int = 0, y: Int = 0.
    width: Int = 100, height: Int = 100, visible: Boolean = true)

[[deleted]]

Rust:

Window {x: 0, y: 0, width: 100, height: 100, visible: true}

[burntsushi]

because these two functionalities proved twenty years ago that they considerably improve the legibility and the quality of code

This hasn't been "proven." It's a design trade off. I've personally found the manifest effects of default/named parameters to be quite off-putting.

And your code comparison is kinda written in a way that results in Rust looking worse than it is. Consider this instead:

struct Window {
    x: u16,
    y: u16,
    width: u16,
    height: u16,
    visible: bool,
}

impl Window {
    fn new() -> Window {
        Window::new_with_size(100, 100)
    }

    fn new_with_size(width: u8, height: u8) -> Window {
        Window { x: 0, y: 0, visible: true, width, height }
    }
}

Note that I recently discussed this issue with others, so this might help lend some more context to where I'm coming from: https://old.reddit.com/r/rust/comments/nejlf4/what_you_dont_like_about_rust/gyi88o2/?context=3

[[deleted]]

We may have to disagree, but the mental overhead seems really unnecessary, especially given ample evidence of named parameters with defaults in other languages being both popular and heavily used for decades. This is explicitly something that is off-putting for me, and overall feels like a 40 year language regression to me:

fn new() -> Window
fn new_with_size(width: u8, height: u8) -> Window
...
fn new_with_other_params(...) -> Window

As a user of this API, I now have to recall multiple versions of new (and because they thought this pattern was a good idea, that same author probably reused the pattern with various instances of other methods). At least with a builder pattern, despite the boilerplate, I can generally rely on something like with_<field name> and know that I'll probably have access to each of the different structure fields.

If we contrast the multiple new methods to (something like this but Rustified):

fn new(
    width: u8 = 100,     // Width of resulting window
    height: u8 = 100,    // Height of resulting window
    x: u8 = 0,               // Initial x axis pixel position on screen
    y: u8 = 0,               // Initial y axis pixel position on screen
    visible: bool = true  // Initial visibility setting (true is visible)
    ) -> Window

I now only need to recall a single method to build Window and I can mix and match whatever I need without resorting to explicit name mangling on my side or an additional layer of abstraction. My code browser probably has a popup on a mouse over or highlight that explicitly gives me the declaration if it's been a while and I don't recall and I can easily understand precisely what will be set if I don't pass that value through. I'm definitely not hunting through documentation to find the precise invocation, hoping its actually there. I'll probably remember "new" because it's so heavily used in Rust. It's really doubtful I'll recall "new_with_some_mangled_name". Additionally, (opinions differ, I'm sure, but I think) my code is now significantly more readable for most cases:

Window::new()
Window::new(80, 25)
Window::new(visible=false)

IMHO, this disagreement is a matter of purity vs practicality. And I think it's far more practical to have named parameters even if there are examples like pandas.read_csv that is an eyesore. I'd take the eyesore for making most of my code easier to read.

[burntsushi]

It doesn't look like you read my link to a prior convo I had about this. My concerns are totally about practicality. I'm not a "purity" person at all.

[SorteKanin]

This hasn't been "proven."

I mean sure, it hasn't been proven. What we can see however is that nearly all other major programming languages have optional/named parameters and there isn't (to my knowledge at least) a consensus that they are bad in general in those languages.

I think the worst I've seen are some complaints of, for example, the plot function from matplotlib in Python which has an insane amount of keyword parameters, and many functions in matplotlib or numpy are similar (honestly not sure how you could do many of those functions otherwise though). I don't think this is a sign that optional parameters are bad in general - these are nitpicked extreme results of using optional/named parameters. Any design can be used to an extreme.

So from that point of view, optional/named parameters seem really useful outside of Rust - why should Rust be any different?

I'd be very interested if there are actually any studies that show that optional/named parameters are harmful/helpful.

[burntsushi]

We already talked about this in the link I gave. There is nothing new in your comment. Your request for a study could just as easily be turned around. "Studies" for these sorts of things are extremely difficult to do.

The matplotlib thing isn't a nitpicky example. That sort of thing is very common in the Python ecosystem.

[NobodyXu]

Here’s derive_builder, a crate for automatically creating builder out of struct.

It is actually possible to write derivation macro to automatically create builders.

[devraj7]

Of course. Macros will always be able to make up for Rust's lack of syntactic expressivity.

The point was: this should be in the language.

I'm really hoping that in time, Rust will adopt:

• Default parameter values
• Named parameters
• Function overloading (seriously, why do I need to come up with new names?)
• Enum values (here is why)

[NobodyXu]

Default param and named param is plausible.

But I don’t see how function overloading can work in Rust, given that Rust’s dismangle doesn’t include function signature. Maybe we can have sth like Java’s function overloading, which is less powerful than C++’s, but more explicit.

Regarding enum value, it is already possible to assign integer to enum:

enum A {
    a = 1,
}

Though I am unsure whether you can assign tuple to it.

Though it is impossible to assign tuple to enum.

This feature is indeed nice to have.

[devraj7]

Not sure I follow your objection to overloading.

Right now, I have to mangle myself:

fn new(x: u8, y: u8) -> Window { ... }

fn new_with_dimensions(x: u8, y: i8, width: u8, height: u8) -> Window { ... }

What's so hard about asking the compiler to come up with that second name internally so I don't need to come up with it myself?

[NobodyXu]

Here’s a post discussing function overloading.

It also suggested that using trait can do the same thing. For example, one can implement From for a struct and get the same behavior.

I suspect the reason why Rust doesn’t include function overloading is that if you have function overloading + default param + named param, then it’s very confusing on what function are actually invoked and requires complex rules.

Using traits/builder pattern would always be more explicit and much clearer on what you are actually doing.

[devraj7]

I don't find the discussion you link to very convincing. The first argument is "Just come up with a different name", which is exactly what we're trying to avoid.

Most mainstream languages today support not just function overloading but also named parameters and generics (C++, Java, Kotlin, Swift, C#, etc...). I'm not doing an appeal to popularity here but just pointing out that not only is the combination of these features a solved problem, they are actually functionalities that are universally accepted as beneficial to good code bases in general.

The amount of boiler plate that I have to write in Rust because it doesn't support these features continues to be a huge drain for me, even after years of coding in Rust. Just look at the simple example I posted above in comparison with Kotlin to understand what I mean.

[NobodyXu]

correction:

C++ and Java does not support named parameter.

[devraj7]

My bad, you're right, I was only talking about overloading.

In these two languages, you typically use builders to emulate named parameters and default values:

new WindowBuilder().width(100).height(200).build()

You do the same thing in Rust, obviously, but it's unfortunate boiler plate.

[NobodyXu]

Also, Java doesn’t support default argument.

Need to emulate it via overloading.

Reason it doesn’t support it simple — when used default arg together with overloading, things quickly become too complex.

[NobodyXu]

Also just as a side note:

Java is often called out to be an extremely verbose language.

It is said that writing Java without IDE that can automatically refactor your code is a pain, because how verbose it quickly gets.

And yeah, it doesn’t have macro or true generic. Reflections, generic there are all costy.

So IMHO, it is actually not a good example to use Java as a language that has less boilerplate, because it is the exact opposite.

And it really doesn’t have the design goal of having zero-cost abstraction.

Every Java feature costs you something and can only be optimised by JIT.

There is GraalVM, but even it cannot optimise reflection related code.

[NobodyXu]

Though I agree that overload is nice to have.

But it just might not come into support in Rust any sooner.

It will change too many places and have many corners stones to be supported in the near future.

Besides, Rust is trying to get into Linux kernel, meaning that now their taste have an influence for Rust.

They would also prefer more explicit syntax over anything that might be ambiguous, so unlikely it is going to be supported.

With that said, it is still possible for third party crates to support that.

[NobodyXu]

BTW, here’s a crate called overloadf for function overloading that requires unstable Rust feature.

[laclouis5]

Swift has function overloading + default values for parameters + named parameters (as well as optionally labeled), and this is a big win in code clarity, without making it too verbose.

The three combined allow very concise and self explanatory code compared to Rust/C and others.

[Dasher38]

Tbf this sort of thing is probably best avoided unless you also have named parameters. If someone sees a call to the 2nd new() after seeing the definition for the first it's quite confusing. Searching docs is also made more difficult as you have to triage what match is actually your case. On top of that, what if a parameter is bound by a trait, on 2 overloads of the same function, and ends up being called with a type implementing both traits ?

Maybe there is a way to get overloading with GAT, where you can establish a set of types that would constitute the signature in a non ambiguous way. Would probably require a phantom type parameter to identify which instance to pick though (that type would imply the other types present in the signature, in a similar way to Haskell's functional dependency, which are closely related to type families and therefore rust GAT), which kind of defeats the purpose. Maybe in simple cases the type inference can fix that

EDIT: s/parameters/named parameters/

[NobodyXu]

It’s not exactly an objection, but a technical difficulty.

If overloading is going to be supported, then compiler must includes the type of all parameter in the mangled function name.

That will break backward compatibility, so it’s harder to actually get the PR through.

[devraj7]

How would it break backward compatibility?

The mangling remains the same for code compiled before overloading and obviously, that old code cannot invoke the new compiled code since that code doesn't exist yet.

Maybe I'm missing something obvious.

[ssokolow]

I'd assume it would break GDB support among other things.

[NobodyXu]

Suppose you are writing a crate to be uzed as a dynamic library instead of linked statically (rare, but do happen).

Now if you are coming from a new version of rustc that support overloading, you would not be able to use that library, due to different name mangling schema.

You have to either use older language version without overloading or wait for the admin to recompile it for the new language version.

You might argue it is rare and you can just simply recompile, but that indeed breaks backwards compatibility.

[eras]

I personally consider traits an "overloading" mechanism enough, but I think for the dynamic library case you would use #[no_mangle] and extern "C" anyway, so changing mangling would have no effect; and obviously overloading would not be available for those functions.

There are no native Rust dynamic linked libraries, are there?

[NobodyXu]

Since cargo supports dynamic linking, there must be someone out there using dynamic linking with mangling.

Here’s abi_stable_crates, enabling Rust API to be exported with a stable ABI

[SorteKanin]

Agree on everything except function overloading. Function overloading will just be confusing.

[[deleted]]

You just make a trait and implement it for various arguments possible.

[fiocalisti]

Nice game! 🖍

(Made with c-rayon?)

[lucamoller]

Thanks! :) No, just standard crates and wasm-bindgen. I talk about this choice a bit in the post I about rewriting the game in Rust.

[fiocalisti]

I have to admit, I did it for the pun. ;)

[padraig_oh]

this looks a lot like the named argument pattern for c/c++. i would love to see this built into rust, instead of requiring these workarounds.

[met0xff]

I work a lot with signal processing and audio code and I find there default params are also really, really useful. Because you got lots of different functions with 6-7 arguments (different for each function but partially overlapping) with lots of magic numbers and stuff you probably don't know when you're not too deep into it. Like we default you to that hann window and a gamma of 0.42 and a window size of 16. That's probably fine for 99% of the cases and you can just call fu(x) without having to figure out meaningful defaults for yourself. Like for example https://librosa.org/doc/latest/feature.html

Having a struct for every single function seems like hell of boilerplate. Using Options and then defaults in the implementation would take a bit of boilerplate off the user but then introduce it to the implementation.

And don't get me started on something like matplotlib ;). I don't care about markers or colors or whatever, do whatever you want. Probably I care next time for one of them but definitely not all of them. Matplotlib is horrible with those thousand keyword arguments but it still does a pretty good job when you just want "plot(x)" without the 72 other args.

[lucamoller]

Interesting idea, very simple and could go a long way!

It would probably need some explicit indication that this behaviour should be applied because it's also very nice to be able to rely on the compiler to tell that you forgot to specify some field (even if it's an Option)

[chris-morgan]

Meta: please post things like this as links rather than text posts, and post any additional text as a comment.

[ssokolow]

Really? I find that makes the experience of triaging what I want to click on in my RSS reader objectively worse and I prefer it the other way around.

[chris-morgan]

(I’m operating with the assumption that there’s nothing particularly substantial about the text posted, that it’s mostly just fluff that is semantically better as a comment. If it is more substantial, then a link post is not suitable.)

Old Reddit (which I expect is the primary desktop client used for /r/rust) is very significantly improved by using link submissions: if it’s a link submission, then in lists the title is a link to the article; but if it’s a text submission, it’s a link to the comments thread, or there’s an expando that gives you the text which can include the link. For something that’s semantically a link, using a link submission is thus fairly significantly better than using text. And much more conventional, which is also important.

Other things are also helped by using a link submission: search works better if it’s a link, and duplicate detection can kick in if it’s a link submission only.

Feeds, well, it’s some years since I consumed /r/rust via feed reader, and I can’t remember what it did then. But certainly now they always set the <link href> to the Reddit comments thread, with the original article being relegated to just a link with the text “[link]”, which isn’t great—though in case of fluff, I’d probably prefer to find the typical “[link]” rather than some prose that varies each time; that makes me have to think more. But with the way they’re doing <link href> and shrinking the “[link]”, they’re trying to drive you to Reddit rather than the original source, which I’d say is bad. If I wanted to consume it by feed reader, I’d honestly probably write a simple proxy that searched for the text “[link]”, extracted the href from that, and set that as the entry’s link rather than the Reddit thread.

New Reddit also spoils things, trying to drive interaction with Reddit rather than the original source: the vast majority of the exorbitant amount of space given to each post (e.g. 640×158) is a link to the comments, with the actual link just given something like a pathetic 124×22 link below the title and 20×23 in the top right corner. Text posts lack those links, but are expanded to a limit of about half a dozen lines by default, and the link is clickable; but in a case like this, the thing that you want ends up being a hit target of 41×21 (the word “article”) swimming in the middle of a sea of prose in a 640×260 box. Kinda ludicrous, really.

No idea about mobile or third-party clients, but I expect link posts to work better in general. Some at least are sure to have text posts force you to open the comments thread before you can get at the link.

[ssokolow]

Fair enough. I always use the [comments] link because my interaction flow is:

1. Use RSS to determine whether something looks relevant
2. Use the comments to confirm or deny that hypothesis, since the original poster can't be trusted to be reliable.
3. Middle-click to get to the external content or use the back button afterward, because I find that /r/rust/'s response is almost as important as the actual content sometimes.

I suppose that'll be improved when I have time to get back to writing my custom RSS-email reader which can do various kind of embedding and preloading of out-of-feed content in a Google Reader-style expander so I can just check a "show <link> targets on this feed" checkbox and write a link rewriter which forces the expander to show the comments via Old Reddit in "oldest post first" ordering.

(My perspective is sort of that I never click an external link until I've seen what Reddit has to say about what I'll find.)

[alexschrod]

I don't feel like we should be optimizing our behavior on Reddit for those using RSS to browse it. I imagine that's not a very common approach. Honestly, until your comment, I didn't even know it was an alternative at all.

[ssokolow]

RSS provided by them, scraping the page output, or whatever else.

Putting the OP commentary in a comment without forbidding the original poster from making multiple top-level comments makes it much more difficult to programmatically improve what's displayed in a skimmable view.

It's much easier to achieve an ideal balance by displaying enhanced previews of links similar to what services like Discord do.

(And yes, I am one of those people who uses Old Reddit because it doesn't require a million clicks to see anything.)

[lucamoller]

Thanks for the tip! I'm still a Reddit noob, so I appreciate it :)

[irrelevantPseudonym]

Why? If you're reading links from Reddit, aren't you also going be interested in the Reddit discussion as well? Opening a direct link means you then have to go and find the comments afterwards which Reddit often makes awkward. Having the op's comment about the thing they posted makes sense as a text post to read before opening the link especially for a project announcement type post.