News for hackers. Stuff that matters.
Re:Names are not type safety by aliceryhl on Monday November 02, 2020 @04:29AM (#24966160)
The Rust standard library has many examples of exactly this, except with unsafe to assert that the unreachable cases can't happen. A classic example is the String type, which is just a newtype around Vec<u8>. Other examples include CStr, NonZeroUsize and PathBuf.

Arguably even File is an example of this. Internally, it's just an integer for the file descriptor.

Re:Names are not type safety by the_mitsuhiko on Monday November 02, 2020 @04:36AM (#24966204)
> has many examples of exactly this

Exactly what? I'm not sure what you're referring to here exactly.

Generally newtypes in Rust are not used excessively and largely for sensible safety assertions. I don't see people making `EmailAddress(String)` newtypes.

Re:Names are not type safety by aliceryhl on Monday November 02, 2020 @07:13AM (#24967245)
Of newtypes. I gave several examples of them. The String type _is_ a newtype that outlaws some of the possible values of the underlying type, namely non-utf8 byte sequences. I wasn't talking about people using Rust, but about the standard library.

That said, I have personally used newtypes a reasonable amount, mostly for making sure I don't mess up different kinds of database ids.

Re:Names are not type safety by chrisoverzero on Monday November 02, 2020 @09:43AM (#24968610)
> The String type _is_ a newtype that […]

It is not. `NonZeroUsize` is (though in Rust "newtype" is only a pattern or idiom), and its definition (inside of a macro which provides numeric newtypes a bunch of `impl`s) is:

    pub struct NonZeroUsize(usize);
But here's String:

    pub struct String {
        vec: Vec<u8>,
    }
…which is a normal `struct` _containing_ a named `Vec<u8>`. Of the types you mentioned, only `NonZeroUsize` conforms to the pattern.
Re:Names are not type safety by aliceryhl on Monday November 02, 2020 @11:48AM (#24970092)
The point of a newtype is that it allows you to create a wrapper around some other type for one of the following two purposes:

1. Marking the kind of data to prevent mixing up values of different kinds. (e.g. Email)

2. Outlawing some of the values of the underlying type. (e.g. OneToFive)

I do not think it being a tuple-struct or not is important at all when deciding whether something uses the newtype pattern, as long as it has a single field.

Re:Names are not type safety by steveklabnik on Monday November 02, 2020 @10:38AM (#24969239)
Do you feel that just because the inner value is named, rather than unnamed, it’s no longer a new type? Trying to figure out what line is crossed here.
Re:Names are not type safety by chrisoverzero on Monday November 02, 2020 @12:32PM (#24970677)
I'm going by the Rust documentation: https://doc.rust-lang.org/stable/rust-by-example/generics/ne...

(I was going to be cheeky here, but Git history shows you didn't write any of this part.)

Re:Names are not type safety by steveklabnik on Monday November 02, 2020 @03:05PM (#24972551)
Hehe yeah, I mean, I am not 100% sure myself, which is why I asked.

There's no real difference between a 1-tuple struct and the regular struct, other than the name. So to me, it feels like either are both newtypes. But, I guess I could see some sort of argument the other way too.

Re:Names are not type safety by lexi-lambda on Monday November 02, 2020 @05:38PM (#24974307)
In Haskell, a newtype can be a single-field record with a named field, so from a Haskell perspective, I would definitely consider both of them “newtypes.”
Re:Names are not type safety by runeks on Monday November 02, 2020 @05:24AM (#24966469)
> Exactly what? I'm not sure what you're referring to here exactly.

"Newtypes as tokens"

Re:Names are not type safety by ChrisSD on Monday November 02, 2020 @04:41AM (#24966235)
Why not? That would seem useful if other code depends on having a validated email address.
Re:Names are not type safety by the_mitsuhiko on Monday November 02, 2020 @04:56AM (#24966311)
I point you to the article.
Re:Names are not type safety by ChrisSD on Monday November 02, 2020 @05:03AM (#24966350)
The article doesn't exactly make a case against it. It even explicitly says it's useful! It just says making a newtype isn't as strong a guarantee as a proper type.

Newtypes do work to assert certain checks have already been done and need not be repeated.