newtype / generalized newtype deriving

[rust-highfive]

Pretty

Tracking issue for postponed PR #186

[alexchandel]

An attribute like #[derive_newtype], applicable to "newtype" tuple structs like struct Wrapper(i32), would be fantastic.

[reem]

The interaction with TypeId and Any here is also of note, since an incorrect implementation of newtype deriving can cause serious problems when combined with downcasting - if get_type_id from Any is inherited such that it reports the same TypeId for the original type and the new type, bad things can be made to happen.

[aidancully]

If it's discovered that a keyword is required to support newtypes, if the language follows semver (and I seem to recall that it does), would that require that rust be bumped to 2.0 just to add the keyword? (since it's a breaking change when existing code that uses the token "newtype" stops working.) Wouldn't it be more conservative to reserve the keyword now, and release it if we can determine that the functionality can be implemented with a macro or some such?

[Kimundi]

Afaik the official stance is that keywords can be added without bumping the major version by adding an attribute for enabling them.

[nikomatsakis]

Postponed RFC #949 contains a description of a possible newtype semantics.

[drewm1980]

Shouldn't something like this be a 1.0 blocker? It seems like you don't want people rolling their own solutions to get around a pain point in something as fundamental as newtype.

For example, it would be nice to be able to do checked addition, max_value(), etc... on a newtyped int without a bunch of boilerplane:

http://is.gd/7Cdzkd

Credit: this came from help I got during an IRC discussion with flan3002.

Thanks! And sorry if commenting on two related issues is considered a cross-post; not sure about ettiquet on this. This seems to be the higher priority / still open thread...

[Diggsey]

There seems to be a forwards compatibility problem with this RFC in combination with the coherence rules: even under the new rules proposed by @nikomatsakis in #1023 this would mean that a parent crate cannot add a new trait implementation to a type "Foo", without potentially breaking downstream crates, which may have newtyped "Foo" to "Bar", and then implemented that same trait for Bar.

[arienmalec]

Reference to quasi #[derive] proposal

https://users.rust-lang.org/t/has-there-been-a-rejected-rfc-on-derive-attributes-for-newtypes/2026/2

[arienmalec]

Just to put more info into the thread: my proposal is more like the first alternative, supporting #[derive] -- is the newtype keyword even feasible post 1.0?