Baking-in some coding patterns?

Rust 1.0 design contains lot of best coding practices from languages like C++. In the years since Rust 1.0 lot of Rust code has being written, we have gained experience of several new Rust-specific usage patterns. Some usage patterns have being borrowed from other languages (like functional languages, see below). Rust design tries to be very orthogonal and to avoid special cases as much as reasonably possible (unlike Swift that I think prefers some more specialized solutions), and in my opinion this has given mostly advantages. Do you want some of those Rust coding patterns to become shorter and simpler to write, for future Rust versions or for future languages derived from Rust? This could add some special cases to Rust, but it could also encourage the usage of those good patterns, making them more common and natural.

An example of Rust coding pattern (here implemented in Haskell): https://wiki.haskell.org/Smart_constructors

Another "coding pattern" I like are the interval integrals from Ada, that even the stabilization of Rust generics and library-defined interval integrals could not make them a widely used coding pattern in Rust (and making them library-defined can't make them integrated enough with the rest of the language as in Ada compilers).

No.

As I explained earlier, even though Rust is pretty opinionated about memory safety (that is perhaps the main point of the language), apart from enforcing correctness, it doesn't enforce any particular style. This is a great and important distinction to make, and hard-coding such patterns would actually be detrimental to usability (as well as such majestic goals as orthogonality).

The codification of certain patterns is also a substrate for rigidity. As soon as one's use case doesn't perfectly fit a baked-in pattern, they'll be unable to use it and will end up needing to reimplement it.

(This is, by the way, closely related to the common issue of forcing certain patterns on specific problems in a similar manner, which usually also ends up bloating code and introducing unpleasant surprises around the rough edges of the real-world problem that don't fit the textbook implementation of the pattern at hand.)

3 Likes

I think this is too general a question to be answerable.

That said, I encourage you to find a common pattern you find too verbose and post a survey of how it's done in a variety of places, to kick off a conversation. Obviously the default answer is crate- or library-level additions first, but language changes certainly aren't off the table.

That's not necessarily unacceptable -- if it was, we wouldn't have #[derive(Debug)], which also has a big typing jump when it comes to customization.

9 Likes

It doesn't mean that this is good. Nor is this a good example – derive macros are completely user-definable and extensively customizable. I wouldn't at all categorize them as "baked-in", even if some std traits have predefined derive impls – the mechanism and the principle is the same.

1 Like

Isn't this basically the same as the usual SFINAE tricks in C++? This hardly seems rust specific (and, frankly, I don't think that something like that should be any easier to use than SFINAE or the current, equivalent Rust idioms...)

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.