[SE-0474] Support yielding borrow and yielding mutate accessors

[tbkka]

yielding borrow and yielding mutate are the final approved names for the accessors previously known as read and modify (which are themselves improvements over the earlier non-standard _read and _modify accessors).

Since some people are already using these under the read and modify names, we want to support the old and new names as synonyms for a transition period until everyone has had a chance to migrate.

[tbkka]

This isn't working out so well. There seem to be two basic problems:

• Treating yielding borrow as a synonym for read
• Having yielding borrow be a "keyword" that's really two words

[tbkka]

It's not clear from SE-0474 whether yielding mutating borrow should be accepted, or only mutating yielding borrow. @DougGregor @rjmccall -- Any insights here?

If the former is accepted, then it might make sense to model yielding as a modifier here; otherwise, I'll need to do something more complicated.

[tbkka]

Can anyone suggest how this should work? @bnbarham @rintaro @hamishknight ?? I'm completely stumped. What I have here seems entirely wrong, but I have no idea what approach should be used here. In particular:

• Mapping yielding borrow to read breaks round-tripping, so it seems like I somehow need to model yielding borrow as a distinct construct from read
• It seems like yielding borrow must be modeled as two Nodes? Otherwise, trivia between those tokens can't be modeled?
• yielding can't be a "modifier" without other changes, since mutating yielding borrow is legal, and that would have two modifiers, which isn't supported in the current accessor modeling. So either accessors need to support a set of modifiers? Or something different?

[tbkka]

This breaks round-tripping, so I can't do this mapping here.

[tbkka]

Maybe I could expand AccessorIntroducer with a new yielding field like this?

  struct AccessorIntroducer {
    var attributes: RawAttributeListSyntax
    var modifier: RawDeclModifierSyntax?
    var yielding: RawAccessorYieldingSyntax?
    var kind: AccessorDeclSyntax.AccessorSpecifierOptions
    var unexpectedBeforeToken: RawUnexpectedNodesSyntax?
    var token: RawTokenSyntax
  }

and then I'd have to reverse-engineer the code generator to construct RawAccessorYieldingSyntax and update everywhere an AccessorIntroducer was used to properly handle the new field? Does that make any sense?

[tbkka]

It would be so helpful if the generated code included comments indicating where the data came from for each particular generated type and/or file.

[bnbarham]

It's not clear from SE-0474 whether yielding mutating borrow should be accepted, or only mutating yielding borrow. @DougGregor @rjmccall -- Any insights here?

I haven't been following the proposal closely, but from a quick read, it has eg.

Like a set accessor, a yielding mutate accessor in a struct or enum property is mutating by default (unless explicitly declared a nonmutating yielding mutate)

Confusing set of terms IMO (nonmutating mutate?), but set accessors allow specifying mutating (despite being redundant), so seems reasonable to allow here.

yielding can't be a "modifier" without other changes, since mutating yielding borrow is legal, and that would have two modifiers, which isn't supported in the current accessor modeling. So either accessors need to support a set of modifiers? Or something different?

Given the proposal mentions the possibility of a non-yielding borrow/mutate, seems that yielding is most like a modifier. So yes, I'd go with:

So either accessors need to support a set of modifiers?

The next question is whether there should be an order to these, ie. is yielding nonmutating mutate allowed?

[tbkka]

These changes to Declarations.swift seem to make sense to me. This should verify the basic syntax.

[tbkka]

I need to either add a new field here or change modifier to an array. No idea which is more appropriate.

[tbkka]

What does this mean?

Build of product 'generate-swift-syntax' complete! (0.08s)
SyntaxSupport/Child.swift:370: Fatal error: unexpected node has no siblings?