@dataclass(slots=True) adds slots to dataclasses. It adds a slot per field. 
However, it doesn't account for slots already present in base classes:

>>> class Base:
...     __slots__ = ('a', )
...
>>> @dataclass(slots=True)
... class Foo(Base):
...     a: int
...     b: float
...
>>> Foo.__slots__
('a', 'b')  # should be: ('b', )


The __slots__ documentation says:

    If a class defines a slot also defined in a base class, the instance variable 
    defined by the base class slot is inaccessible (except by retrieving its descriptor 
    directly from the base class). This renders the meaning of the program undefined. 
    In the future, a check may be added to prevent this.

Solution: don't add slots which are already defined in any base classes:

>>> @dataclass
... class Bla(Base):
...     __slots__ = ('b', )
...     a: int
...     b: float
...
>>> Bla(4, 5.65)
Bla(a=4, b=5.65)

If you agree, I'd like to submit a PR to fix this. I already have a prototype working.

I'll have to do some more research. But your analysis looks correct to me, so far.

There are already 2 complexities I can think of:

1. This behavior may break some people's code, if they use __slots__ to iterate over
   the fields of a dataclass. Solution: explicitly mention in the docs that
   not every field may get a slot on the new class. Advise them to use
   `fields()` to iterate over the fields.
2. It's technically allowed for __slots__ to be an iterator (which will then be 
   exhausted at class creation). Finding the __slots__ of such a class
   may require more elaborate introspection.

Arie, can you please explain what is the technical difference between these two cases:

```python
class A:
    __slots__ = ('a', )
    # fields

class B(A):
    __slots__ = ('a', 'b')
    # fields
```

And:

```python
class C:
    __slots__ = ('a', )
    # fields

class D(C):
    __slots__ = ('b', )
    # fields
```

?

Both will function, but class B will add its slots after A's, causing there to be an extra unused slot in the object that you can only access by directly using the A.a descriptor. So all slotted inheriting dataclasses cause the object to use more memory than necessary.

Spencer is correct.

The documentation even adds: "This renders the meaning of the program undefined."

It's clear it doesn't break anything users would often encounter (we would have heard about it), but it's still undefined behavior.

It would also be interesting to see what attrs does in this case.

>>> @attrs.define
... class C(Base):
...   a: int
...   b: int
...
>>> C.__slots__
('b', '__weakref__')

We've got a test specifically for this use case: https://github.com/python-attrs/attrs/blob/5f36ba9b89d4d196f80147d4f2961fb2f97ae2e5/tests/test_slots.py#L309-L334

@hynek interesting! 

The discussion in https://github.com/python-attrs/attrs/pull/420 on the weakref slot is very interesting as well.

Considering __weakref__ is something we don't want to make impossible in dataclasses, @eric.smith what would be your preferred solution?