Consider creating a version of struct with different defaults (class?)

[nikomatsakis]

Issue #8380 highlights the fact that via implicitly copyability we have a similar situation to C++ copy constructors: one must "opt out" of copyability. Perhaps we can do better? One thought is to have structs with private fields by not implicitly copyable.

UPDATE: Changing title to reflect a desire for something that works like a struct but with distinct defaults. See this comment

[nikomatsakis]

Nominating

[glaebhoerl]

I like this. It seems weird (and an abstraction leak) for a type to be either copyable or not based on information (private fields) that you can't see.

[thestinger]

I'm strongly against doing this. It would make built-in types even more special-cased and further reduce the ability to define full replacements in the standard library. A built-in type shouldn't be able to do anything a library type can't do.

[nikomatsakis]

I'm strongly against doing this. It would make built-in types even
more special-cased and further reduce the ability to define full
replacements in the standard library.

Hmm, possibly? Depends if it were just a matter of defaults, or
something that would be overridden.

More and more I am coming to the opinion that we need a distinct
class and struct (yet again I find I admire C++). In my view, a
class would have very different defaults from a struct which are all
oriented around encapsulation:

• not implicitly copyable,
• fields private,
• fields must be declared mutable to be mutated,
• (perhaps) not creatable via Foo { ... } expressions outside the
  module where the class is declared.

whereas a struct would be what we know and love today.

The last point is something that's been rattling around in my brain
lately. We removed field-level mutability because it interacted poorly
with inherited mutability, but that is partially because of the way
that we interpreted it ("always mutable"). Another interpretation of
field-level mutability would be "mutable if uniquely reachable", which
is how we interpret &mut today. In that case, we could go back to
mut fields. Fields not declared mut would not be directly
assignable; of course they could still change value if the entire
struct/class is overwritten as a whole, but they can't be changed
indepdendently. These rules would play nicely with the borrow checker
and address the desire to have fields that can only be set when the
struct as a whole is initialized.

[thestinger]

I think allowing implicit copies is by far the common case, so while it makes sense to have #[non_copyable] I don't think it makes sense to make it implicit copies opt-in. I think unsafe code is the only reason why you would want to forbid copies, and most Rust code isn't going to use unsafe.

[glaebhoerl]

@thestinger, you have a point. On the other hand, with the rule that a struct is implicitly copyable if its fields are, it means that for a struct with private fields,we're telling people to look at private declarations to figure out whether it's copyable. But they shouldn't be looking at that! It's private for a reason! Doesn't that bother you a little bit?

[thestinger]

The documentation generator could tag types that have move semantics. I agree it's currently a problem, but I think it's a rustdoc problem :).

[thestinger]

It should also tag whether types are Freeze and/or Send.

[thestinger]

#10431

[nikomatsakis]

I don't think that memory safety is the only reason for a type to be not implicitly copyable and I am not at all sure that "most" types ought to be copyable. I think that'll depend quite a bit on the specifics -- many types ought not to be copied for semantic reasons.

[pnkfelix]

I don't think anyone has yet mentioned on this bug: there is the std::util::NonCopyable zero-size struct.

If you add that as a field to a struct, it becomes non-copyable.

[pnkfelix]

We can leave the semantics as they are for 1.0, and worry about adding something like the class form suggested by Niko later.

[pnkfelix]

(declining for assigning a priority). or rather, P-low.

[Aatch]

If anybody is still interested in this, an official RFC should be filed. https://github.com/rust-lang/rfcs/blob/master/active/0001-rfc-process.md