Nick Smith

At the risk of being hypocritical—given my last comment—I'll share another thought on names that I just had. This proposal is currently entitled as one of: - linear types -...

We should also investigate how trivial destructibility (the ability to get rid of a value *without* invoking `__drop__` on it) fits into this whole story. Maybe we need both "droppable"...

People subscribed to email notifications may have noticed me rambling about trivial types just now. Just ignore that. I've deleted those messages because they don't really have anything to do...

To follow-up: [On Discord](https://discord.com/channels/1087530497313357884/1224434323193594059/1320184811226136638), Owen and I discussed the need to have a trivial equivalent of the `Copyable`, `Movable`, and `ImplicitlyDestructible` traits. We agree that we need all six of...

Hmm... I'm starting to think that the most sensible name for `ImplicitlyDestructible` would be `Deletable`. Rationale: - `Deletable` has a single method, `__del__`. It's nice that the method name matches...

Also: at the time of writing, Mojo has the traits `ExplicitlyCopyable` and `Copyable`. Hopefully, when the dust settles, implicit copying and implicit destruction—or lack thereof—will be expressed using the same...

Can I suggest that if we're going to introduce the keyword `static`, we aim to combine both the C++ meaning ("static storage duration"), and the more fundamental meaning of the...

@bgreni > `alias` also serves a similar purpose to `using` in c++. In my opinion `alias` fits this purpose very well, and `static` looks very awkward. `static Float64 = SIMD[DType.float64,...

One last comment on keywords: Mojo will soon need to support the declaration of **field aliases** in traits, for example: ```mojo trait Entity: fieldalias id: String struct Customer(Entity): var registration_number:...

I agree that there's not really a benefit to using the same module names as Python and then having the contents of those modules be completely different. (And the module...