> Currently, disabling lazy imports disabled the syntax keyword, which means that you can’t use it for circular imports, type checking, etc.

Imo this is a good thing, laziness shouldn't be semantically important. The ability to force disable laziness while maintaining semantics is important for linting and testing, and more often than not, circular imports are a sign of bad code structure.

I assume that by this you mean figuring out some kind of dietary restriction?

I also struggle with a lot of those things (also ADHD) plus other inflammation-related issues (ezcema), and noticed a very specific pattern of fatigue during the day that improves at night. It's hard to tell what might be effective or not since keeping stability in my routine is a struggle, but I've mostly came up empty on explanations/solutions so far.

The argument for 0-256 feels compelling when thinking about the physical display, but it seems like a very poor fit for any digital image processing or rendering.

  enum AllocError {
    SizeTooLarge { size: usize },
    // etc.
  }

If you need $6 to pay for parking, and the largest commonly available coin is a quarter, that means you need 24 coins to pay. If the value of currency was such that the parking only costed $3, or if dollar coins were more common, you'd need less coins to pay.

It's required to do any intialization, particularly for compound futures (e.g. a "join" or "select" type of combinator), since you need to be able to move the future from where it's created to where it's eventually used/polled. I assume some of those cases could be subsumed by &uninit if that existed yeah.

For 3, some objects only need to be pinned under certain circumstances, e.g. futures only need to be pinned after they're polled for the first time, but not before. So it's convenient to separate the pinnability property to allow them to be moved freely beforehand.

I don't quite understand the usecase you have in mind for 4.