Skip to content

Commit 812dbbb

Browse files
committed
[docs] LibraryEvolution: Eliminate the @fixed property attribute.
After talking to Slava, it seems like this really is the same guarantee as @inlineable on a property. See also the next commit.
1 parent 873e023 commit 812dbbb

File tree

1 file changed

+0
-37
lines changed

1 file changed

+0
-37
lines changed

docs/LibraryEvolution.rst

Lines changed: 0 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -605,43 +605,6 @@ were absent.)
605605
We really shouldn't care about the *order* of the stored properties.
606606

607607

608-
Fixed Properties
609-
----------------
610-
611-
As shown above, the ``@fixed_layout`` attribute promises that all stored
612-
properties currently in a type will remain stored in all future library
613-
versions, but sometimes that isn't a reasonable promise. In this case, a
614-
library owner may still want to allow clients to rely on a *specific* stored
615-
property remaining stored, by applying the ``@fixed`` attribute to the property.
616-
617-
.. admonition:: TODO
618-
619-
Is it valid for a fixed property to have observing accessors, or is it more
620-
useful to promise that the setter is just a direct field access too? If it
621-
were spelled ``@fragile``, I would assume that accessors are permitted but
622-
they become inlineable, and so not having any accessors is just a
623-
degenerate case of that.
624-
625-
Is ``@fixed`` any different from just ``@inlineable`` on a property?
626-
627-
Like all other attributes in this section, the ``@fixed`` attribute must
628-
specify in which version of the library clients may rely on the property being
629-
stored. The attribute may not be applied to non-final properties in classes.
630-
631-
.. note::
632-
633-
It would be possible to allow ``@fixed`` on non-final properties, and have
634-
it only apply when the client code is definitively working with an instance
635-
of the base class, not any of its subclasses. But this is probably too
636-
subtle, and makes it look like the attribute is doing something useful when
637-
it actually isn't.
638-
639-
.. note::
640-
641-
This is getting into "diminishing returns" territory. Should we just take
642-
it out of the document for now? We can probably add it later, although like
643-
the other attributes it couldn't be backdated.
644-
645608
Enums
646609
~~~~~
647610

0 commit comments

Comments
 (0)