TODO
General idea: have an easter_egg! macro (TODO think of other name); the goal is to add it in a program as a "if this unlikely condition is met, trigger easter egg".
Later on, a complete test suite needs to trigger all easter egg to get complete coverage.
(alternate name: achievements?)
I'd like to present an alternative to the proposed safe-transmute MCP.
It's centered around three problems I think the current proposal has:
Context parameter of BikeshedIntrinsicFrom introduces new, non-obvious semantics. This is a problem both for implementing it in the compiler, and teaching it to new users.Context is automatically checked, type authors lose some expressivity; by default the ability to transmute a type is tied to its fields' visibility. This has implications for stability (this argument isn't as strong as I though it would be; Jack Wrenn makes some good cases as to how specific use-cases could be covered; still, I think a principled approach would be better)
This is an analysis of the architecture of the Druid framework, and how I think it should evolve in the near future.
Druid is an experimental GUI framework in the Rust programming language; it's somewhere between declarative and object-oriented, and implements a high-level abstraction for platform-specific architectures. It's also the base for crochet, an immediate mode GUI library, and panoramix, a reactive GUI library; both of them extremely experimental.
Recently, Druid's author Raph Levien started talking about the idea of refactoring druid into multiple layers (a simple "backend layer", and one or more frontends like crochet and panoramix). We've discussed possibilities, and Raph has described some (still hypothetical) design decisions that I want to challenge.
Now, separating a framework into tight layers isn't fundamentally a good or bad idea. Sometimes it helps isolate orthog
This article is me fantasizing about what I'd like the Rust language to be like, if we had infinite resources to implement every possible feature. I'm tentatively calling it my "Christmas list for Rust 2030", mostly because it sounds catchy.
For my first Christmas wish, I'd like to discuss conditional compilation and cfg.
There's a virtue of Rust I rarely see discussed. I would formulate it as follows:
| // Everything from here to the --VARIADICS-- marker is valid Rust code right now: | |
| // https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=38f72335b11bda33e3d6787176786a82 | |
| use std::fmt::{Debug, DebugStruct}; | |
| struct StandardDebug; | |
| struct Skip; | |
| struct PlaceHolder(String); | |
| struct CustomFormatter<T>( |
This is an analysis of how variadic generics could be added to Rust. It's not a proposal so much as a summary of existing work, and a toolbox for creating an eventual proposal.
Variadic generics (aka variadic templates, or variadic tuples), are an often-requested feature that would enable traits, functions and data structures to be generic over a variable number of types.
To give a quick example, a Rust function with variadic generics might look like this:
Users should be able hit a "record" button, do a bunch of things, then be given a "Summary of what you just did" that goes:
Modern life is very structured around imperial utilities
Lots of household chores (cooking, cleaning, deliveries) are handled by state-owned corporations.
Status is displayed by having top-tier service from these corporations. Having personal servants is perceived as un-imperial, barbarian, associated with slavery. High-status people don't have personal housekeepers/cooks/etc, they have contracts with high-reputation housekeeping/cooking/cleaning corporations. Since these corporations are state-owned, getting priority service from them involves personal favors and horse-trading.
Check out OCaml modular implicits
https://www.fpcomplete.com/blog/2017/06/readert-design-pattern/