[Proposal] Explicit Synthetic Behaviour

allevato · September 13, 2017, 5:44pm

>
>
>
> >
> >
> >
> > On Tue, Sep 12, 2017 at 9:58 AM, Thorsten Seitz via
swift-evolution
> > <swift-evolution@swift.org <mailto:
swift-evolution@swift.org>
> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>
wrote:
> >
> > Good arguments, Tony, you have convinced me on all
points.
> Transient is
> > the way to go. Thank you for your patience!
> >
> >
> > On many points, I agree with Tony, but I disagree that
"transient"
> addresses
> > the issue at hand. The challenge being made is that, as
Gwendal puts
> it, it's
> > _unwise_ to have a default implementation, because people
might forget
> that
> > there is a default implementation. "Transient" only works
if you remember
> > that there is a default implementation, and in that case,
we already
> have a
> > clear syntax for overriding the default.
> >
> >
> > RightБ─■I hope it hasn't sounded like I'm conflating the two
concepts
> completely.
> > The reason I brought up "transient" is because nearly all of
the "risky"
> examples
> > being cited so far have been of the variety "I have a type
where some
> properties
> > happen to be Equatable but shouldn't be involved in
equality", so my intention
> > has been to show that if we have a better solution to that
specific problem
> > (which is, related to but not the same as the question at
hand), then there
> > aren't enough risky cases left to warrant adding this level
of complexity
> to the
> > protocol system.
> >
> >
> > As others point out, there's a temptation here to write
things like
> > "transient(Equatable)" so as to control the synthesis of
> implementations on a
> > per-protocol basis. By that point, you've invented a
whole new syntax for
> > implementing protocol requirements. (Ah, you might say,
but it's hard to
> > write a good hashValue implementation: sure, but that's
adequately
> solved by
> > a library-supplied combineHashes() function.)
> >
> >
> > I totally agree with this. A design that would try to
annotate "transient"
> with a
> > protocol or list of protocols is missing the point of the
semantics that
> > "transient" is supposed to provide. It's not a series of
switches to that
> can be
> > flipped on and off for arbitrary protocolsБ─■it's a semantic
tag that assigns
> > additional meaning to properties and certain protocols (such
as Equatable,
> > Hashable, and Codable, but possibly others that haven't been
designed yet)
> would
> > have protocol-specific behavior for those properties.
> >
> > To better explain what I've been poking at, I'm kind of
extrapolating this
> out to
> > a possible future where it may be possible to more generally
(1) define custom
> > @attributes in Swift, like Java annotations, and then (2) use
some
> > metaprogramming constructs to generate introspective default
> implementations for
> > a protocol at compile-time just as the compiler does
"magically" now, and the
> > generator would be able to query attributes that are defined
by the same
> library
> > author as the protocol and handle them accordingly.
> >
> > In a world where that's possible, I think it's less helpful
to think in
> terms of
> > "I need to distinguish between conforming to X and getting a
synthesized
> > implementation and conforming to X and avoiding the
synthesized implementation
> > because the default might be risky", but instead to think in
terms of "How
> can I
> > provide enough semantic information about my types to remove
the risk?"
> >
> > In other words, the switches we offer developers to flip
shouldn't be about
> > turning on/off entire features, but about giving the compiler
enough
> information
> > to make it smart enough that we never need to turn it off in
the first
> place. As
> > I alluded to before, if I have 10 properties in a type and
only 1 of those
> needs
> > to be ignored in ==/hashValue/whatever, writing "Equatable"
instead of
> "derives
> > Equatable" isn't all that helpful. Yes, it spits out an error
message
> where there
> > wouldn't have been one, but it doesn't reduce any of the
burden of having to
> > provide the appropriate manual implementation.
> >
> > But all that stuff about custom attributes and metaprogramming
> introspection is a
> > big topic of it's own that isn't going to be solved in Swift
5, so this is
> a bit
> > of a digression. :)
> >
> >
> > That said, we could have enums EquatingKeys and HashingKeys, a la
> CodingKeys... That
> > may not be a huge leap to propose and implement.
>
> Actually, not taking into account a question of explicit marker for
auto-generated
> methods, this is IMO a great point.
>
> Codable, which can auto-generate methods, *had* these CodingKeys
from the moment of
> birth. Currently, we have a proposal for auto-generating of methods
for
> Equatable/Hashable. Why we don't have a EquatingKeys/HashingKeys
option for them in
> symmetry with Codable? Why Codable already has a method to exclude
fields, but for
> Equatable/Hashable we are discussing some future esoteric
'@transient' modifier(which
> should describe the behaviour and destination of the property in
details for compiler
> and conformed protocols so all will "just work") ?
> How this future '@transient' will live together with current
CodingKeys ?
>
> IMO the right solution will be:
> 1. introduce 'deriving'-like keyword to explicitly express that you
request an
> auto-synthesize of protocol requirements
> 2. introduce EquatingKeys/HashingKeys to be able to say which
properties should be
> included in generated requirements
> 3. Think what kind of '@transient' marker could be introduced in
future to replace
> the using of CodingKeys/EquatingKeys/HashingKeys.
>
>
> I don't agree with Xiaodi here that a hypothetical
EquatableKey/HashableKey would be
> the same thing as CodingKey.
>
> CodingKey embeds other semantic information, like the string or integer
key to use
> when encoding/decoding a value in a container. The cases of a CodingKey
enum are also
> actual values that are passed around to other encoder/decoder
methods—they're not
> *just* there for the synthesized code.
>

Can't agree. Yes, they are not *just* for the synthesized code, they have
additional
meaning for _Codable_ protocol. But if you read this

Encoding and Decoding Custom Types | Apple Developer Documentation
, first you find regarding CodingKeys is :
"
Choose Properties to Encode and Decode Using Coding Keys

When this enumeration is present, its cases serve as the authoritative
list of
properties that must be included when instances of a codable type are
encoded or
decoded. The names of the enumeration cases should match the names you've
given to
the corresponding properties in your type.

Omit properties from the CodingKeys enumeration if they won't be present
when
decoding instances, or if certain properties shouldn't be included in an
encoded
representation.
"

So I'd say, that exclusion of fields from participate in Codable, is main
or at least
high important role of CodingKeys. And I can't see why
EquatableKeys/HashableKeys
can't play the same role(without additional meaning CodingKeys has for
Codable).

Well, no. You can't just brush aside all the conditions where using a type
doesn't make sense because there's one place where they act similarly.

CodingKeys contain *data*. That data is used at *runtime*. They are
legitimate values that are passed around as the inputs to other functions
like the encoders and decoders. It's true that the compiler uses that enum
to decide what to synthesize, but the compiler also uses *the values
themselves* in that synthesized implementation.

The hypothetical Equatable/HashableKeys enum would not contain any data. It
would not be used at runtime. It would not be passed around as the inputs
to other functions. It would solely be used by the compiler to determine
which properties were included or excluded in synthesis, but the compiler
would never use its values in the synthesized implementation. By that
definition, it simply does not make sense for it to be a type in the type
system at all, with all the additional type metadata and runtime support
that making it so would bring. If no user—not even the synthesized
implementation—would ever instantiate or operate on that type in any
meaningful way, then there is no reason for it to exist.

···

On Wed, Sep 13, 2017 at 10:03 AM Vladimir.S <svabox@gmail.com> wrote:

On 13.09.2017 19:03, Tony Allevato wrote:
> On Wed, Sep 13, 2017 at 8:41 AM Vladimir.S via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> On 13.09.2017 7:14, Xiaodi Wu via swift-evolution wrote:
> > On Tue, Sep 12, 2017 at 22:07 Tony Allevato < > tony.allevato@gmail.com > > <mailto:tony.allevato@gmail.com> > > > <mailto:tony.allevato@gmail.com <mailto:tony.allevato@gmail.com>>> > wrote:
> > On Tue, Sep 12, 2017 at 7:10 PM Xiaodi Wu < > xiaodi.wu@gmail.com > > <mailto:xiaodi.wu@gmail.com> > > > <mailto:xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>>> > wrote:

Vladimir.

> Equatable/HashableKeys anywhere else,
> passed cases that
> match here. Simply
> put, as values.
>
> I also it would
> augment don't provide
> one. for you there;
> likewise >
> Vladimir.
>
> >
> > > >
> > swift-evolution@swift.org>
> >>>:
> >
> >>
> >>
> >> > >>
> >>>
> >>>> the role of
> >>>> that the core
> team has
> >>>> generic
> algorithms
> >>>> AutoSynthesize
> doesn't
> >>>> algorithms that you
> would
> >>>> what you would
> >>>> > >>>
> >>> and non-avoidable
> >>> > >>>
> >>>
> >>> one of the barriers
> >>> > >>>
> >>> > avoidableБ─■you either
> >>> to the
> protocol and
> >>> differing on is
> >>> switches that you
> >>> > >>
> >> whim. One adds a
> >> to the
> protocol is
> >> code
> synthesis. You
> >> > >>
> >> synthesis. That's the
> >> synthesis is
> >> documentation, if you
> want. But
> >> > >>
> >> one can avoid
> it, by
> >> > >>
> >> adoption *is*
> implicit.
> >>
> >>> of all Swift
> types.
> >>> types that satisfy
> >>> to be
> synthesized.
> >>> the subset of
> >>> is correct
> both in
> >>> and (2) the subset
> >>> but is not the
> right
> >>> transient data.
> >>
> >> > >>
> >>> (2) relative to
> >>> that developers are
> >>> without providing
> >>> complexity worth
> >>> > >>
> >> can evaluate this
> >> > >>
> >> this question
> entirely.
> >>
> >> that developers
> >> > >>
> >> probability that it comes
> >> protocol adoption. And
> >> learn Swift and
> >> because this
> probability
> >> > >> programmer mistake)
> >> conformance later and
> >> > >> transient
> property,
> >> conformance that has become
> >> > >>
> >> And they can't be
> >> > >>
> >> ergonomics
> issue, now.
> >>
> >>> accidental
> >>> barrier to
> smooth
> >>> consider that
> >>> hypothetical ("I'm
> worried
> >>> complexity to the
> >>> conformance) that
> would
> >>> great degree, and
> >>> problem does indeed
> >>> exists with certain
> >>> > >>
> >> a cached
> property
> >> > >>
>
> >>
> >>
> >> actually proves that
> >> approach here.
> (Let's
> >> because we don't
> >> we've gotten that
> >> > >>
> >> > >>
> >> simple Equatable
> >> I tell that value
> >> Later, I decide
> to add
> >> that property
> just
> >> correct thing to do
> >> custom
> >> synthesized operator
> >> arguing that "derive
> >> prevents errors,
> you must
> >> cases where that
> >> > >>
> >> properties and one
> >> The solution
> being
> >> synthesis
> because
> >> "derive", I get an error,
> >> But I have to
> >> ignore the caching
> >> Making it explicit
> >> compiler error for a
> >> we tack on
> Hashable
> >> a significant
> >> Furthermore, if
> >> have to
> declare it
> >> does not occur.
> >>
> >> non-useful dodge that
> >> Swift's type
> >> Equatable
> properties that
> >> instance vs.
> >> "value" of their
> >> behavior based on a
> >> top of those types.
> >>
> >> this: saying "there
> >> incompatible
> with
> >> everywhere" is trying to
> >> is *"how do
> we give
> >> to make the
> >> > >>
> >> have an
> >> and one cache
> >> first 10
> properties. I
> >> me to write all of
> >> compiler which
> >> > >>
> >> type for the
> first
> >> understand? The
> version
> >> init(from:), and
> >> you have to read
> >> sure that the
> >> conforms to those
> >> and has each
> >> more concise and
> >> in a handwritten
> >> > >>
> >> something like
> "transient"
> >> > >>
> >> description, so if
> they do
> >> problem to warrant
> >> conformance system.
> >>
> >>
> >> > >>
> >> > >> > > >>
> > >
> > > > > > >>
> > >
> >
> >
> > > > > >
> > > > > wouldn't be that. The cases would never be used
anywhere, or returned from anything. It would just be a list of
property names, which doesn't really feel like the right model
if the values aren't useful *as values*, they shouldn't be modeled
don't see how "transient" would ever replace CodingKeys. Instead,
it. Right now, the compiler autogenerates CodingKeys if you
What "transient" would do is affect *what* the compiler generates
with Equatable and Hashable. They're not identical concepts.
-Thorsten
Am 12.09.2017 um 16:38 schrieb Tony Allevato via > swift-evolution > > > <swift-evolution@swift.org <mailto:
<mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org
On Mon, Sep 11, 2017 at 10:05 PM Gwendal Rouц╘ > > <gwendal.roue@gmail.com <mailto:gwendal.roue@gmail.com> > > >> <mailto:gwendal.roue@gmail.com <mailto: > gwendal.roue@gmail.com>>> > > wrote:
This doesn't align with how Swift views
protocols, though. One of the criteria
said they look for in a protocol is "what
would be written using this protocol?"
satisfy thatБ─■there are no generic
write with AutoEquatable that differ from
write with Equatable.
And so everybody has to swallow implicit
code synthesis and shut up?
That's not what I said. I simply pointed out
to getting a new protocol added to the language.
Code synthesis is explicitly opt-in and quite
don't conform to the protocol, or you conform
provide your own implementation. What folks are
whether there should have to be *two* explicit
flip instead of one.
No. One does not add a protocol conformance by
protocol conformance by need. So the conformance
a *given* in our analysis of the consequence of
can not say "just don't adopt it".
As soon as I type the protocol name, I get
reason why the synthesized code is implicit. The
explicitly written in the protocol
not in the programmer's code.
I did use "non-avoidable" badly, you're right:
providing its custom implementation.
So the code synthesis out of a mere protocol
Let's imagine a pie. The whole pie is the set
Some slice of that pie is the subset of those
the conditions that allow one of our protocols
Now that slice of pie can be sliced again, into
types where (1) the synthesized implementation
terms of strict value and of business logic,
where it is correct in terms of strict value
business logic because of something like
Yes.
What we have to consider is, how large is slice
the whole pie, *and* what is the likelihood
going to mistakenly conform to the protocol
their own implementation, *and* is the added
protecting against this case?
That's quite a difficult job: do you think you
likelihood?
Explicit synthesis has big advantage: it avoids
Remember that the main problem with slide (2) is
can not *learn* to avoid it.
For each type is slide (2) there is a
into existence with a forgotten explicit
this probability will not go down as people
discover the existence of slide (2). Why?
is driven by unavoidable human behaviors:
- developer doesn't see the problem (a
- the developper plans to add explicit
happens to forget (carelessness)
- a developper extends an existing type with a
and doesn't add the explicit protocol
required.
Case 2 and 3 bite even experienced developers.
improved by learning.
Looks like the problem is better defined as an
If someone can show me something that points to
synthesized implementations being a significant
development in Swift, I'm more than happy to
evidence. But right now, this all seems
that...") and what's being proposed is adding
language (an entirely new axis of protocol
(1) solve a problem that may not exist to any
(2) does not address the fact that if that
exist, then the same problem just as likely
non-synthesized default implementations.
There is this sample code by Thorsten Seitz with
which is quite simple and clear :
ists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039684.html" class="inline-onebox">[swift-evolution] [Proposal] Explicit Synthetic Behaviour
This is the sample code that had me enter the
I really like Thorsten's example, because it
requiring explicit derivation is NOT the correct
set aside the fact that Optionals prevent synthesis
have conditional conformances yet, and assume that
feature as well for the sake of argument.)
Let's look at two scenarios:
1) Imagine I have a value type with a number of
properties. In a world where synthesis is explicit,
type to "derive Equatable". Everything is fine.
some cache property like in Thorsten's example, and
happens to also be Equatable. After doing so, the
would be to remove the "derive" part and provide my
implementation. But if I forget to do that, the
still exists and applies to that type. If you're
Equatable" is better because its explicitness
also accept that there are possibly just as many
explicitness does *not* prevent errors.
2) Imagine I have a value type with 10 Equatable
caching property that also happens to be Equatable.
proposed here says that I'm better off with explicit
if I conform that type to Equatable without
and then I can provide my own custom implementation.
provide that custom implementation *anyway* to
property even if we don't make synthesis explicit.
hasn't saved me any workБ─■it's only given me a
problem that I already knew I needed to resolve. If
and Codable to that type, then I still have to write
amount of boilerplate for those custom operations.
synthesis is explicit, I have *more* work because I
explicitly even for types where the problem above
So, making derivation explicit is simply a
doesn't solve the underlying problem, which is this:
system currently does not distinguish between
*do* contribute to the "value" of their containing
Equatable properties that *do not* contribute to the
containing instance. It's the difference between
type and additional business logic implemented on
So, what I'm trying to encourage people to see is
are some cases where synthesis is risky because it's
certain semantics, so let's make it explicit
fix the wrong problem. What we should be looking at
Swift the additional semantic information it needs
appropriate decision about what to synthesize?"*
That's where concepts like "transient" come in. If I
Equatable/Hashable/Codable type with 10 properties
property, I *still* want the synthesis for those
don't want the presence of *one* property to force
that boilerplate myself. I just want to tell the
properties to ignore.
Imagine you're a stranger reading the code to such a
time. Which would be easier for you to quickly
with custom implementations of ==, hashValue,
encode(to:) all covering 10 or more properties that
through to figure out what's being ignored (and make
author has done so correctly), or the version that
protocols, does not contain a custom implementation,
transient property clearly marked? The latter is
"transient" carries semantic weight that gets buried
implementation.
Here's a fun exerciseБ─■you can actually write
without any additional language support today:
ist.github.com/allevato/e1aab2b7b2ced72431c3cf4de71d306d%5C">https://gist.github.com/allevato/e1aab2b7b2ced72431c3cf4de71d306d\. A
big drawback to this Transient type is that it's not
an Optional because of the additional sugar that
latter, but one could expand it with some helper
to sugar it up the best that the language will allow
I would wager that this concept, either as a wrapper
built-in property attribute, would solve a
cases where synthesis is viewed to be "risky". If we
premise, then we can back to our slice of pie and
in terms of "risky" types are "types that contain
conform to a certain protocol but are not really
shouldn't be included verbatim in synthesized
struggling to imagine a type that fits that
exist, it's doubtful that they're a common enough
introducing more complexity into the protocol
Gwendal
_______________________________________________
swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution