Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error in grammar regarding in-out-expression #193

Open
sarahcantohyatt opened this issue Oct 9, 2023 · 3 comments · Fixed by #199 · May be fixed by #194
Open

Error in grammar regarding in-out-expression #193

sarahcantohyatt opened this issue Oct 9, 2023 · 3 comments · Fixed by #199 · May be fixed by #194
Labels
Content issue A problem in with the book's prose, code, or figures

Comments

@sarahcantohyatt
Copy link
Contributor

Location

https://github.com/apple/swift-book/blob/main/TSPL.docc/ReferenceManual/Expressions.md?plain=1#L64

Description

An in-out-expression is defined as being & identifier.
This is incorrect, and can be seen on line 51 that it's meant to be & expression. (here: https://github.com/apple/swift-book/blob/main/TSPL.docc/ReferenceManual/Expressions.md?plain=1#L51)
I'm assuming this is just a simple error that was overlooked but I will leave a demonstration below of why the version with identifier isn't correct.

Given this example program:

enum A {}

struct MyStruct {
	var a: A
}

func myFunc(_: inout A) {}

func myOtherFunc(s: inout MyStruct) {
	myFunc(&s.a)
}

This is compliable code in swiftc.

Our point of concern is the use of an in-out expression as a parameter in the call to myFunc
There is no possible derivation of this subsection of the code given the production for in-out-expression with identifier rather than expression.
Let us look at some possible derivation paths for myFunc(&s.a)

Possible derivation path: (terminals in bold)

  1. -> function-call-expression
  2. -> postfix-expression function-call-argument-clause
  3. -> primary-expression function-call-argument-clause
  4. -> identifier generic-argument-clause? function-call-argument-clause
  5. -> myFunc generic-argument-clause? function-call-argument-clause
  6. -> myFunc function-call-argument-clause
  7. -> myFunc ( function-call-argument-list )
  8. -> myFunc ( function-call-argument )
  9. -> myFunc ( expression )
  10. -> myFunc ( try-operator? await-operator? prefix-expression infix-expressions? )
  11. -> myFunc ( await-operator? prefix-expression infix-expressions? )
  12. -> myFunc ( prefix-expression infix-expressions? )
  13. -> myFunc ( prefix-operator? postfix-expression infix-expressions? )
  14. -> myFunc ( postfix-expression infix-expressions? )
  15. -> myFunc ( explicit-member-expression infix-expressions? )
  16. -> myFunc ( postfix-expression . identifier generic-argument-clause? infix-expressions? )
  17. -> myFunc ( primary-expression . identifier generic-argument-clause? infix-expressions? )
  18. -> myFunc ( identifier generic-argument-clause? . identifier generic-argument-clause? infix-expressions? )
  19. -> myFunc ( ??? generic-argument-clause? . identifier generic-argument-clause? infix-expressions? )

???- cannot reach a production that will get us &s

Let's look at another possible derivation path.
Picking up from step 12 in the above derivation:
12) -> myFunc ( prefix-expression infix-expressions? )
13) -> myFunc ( in-out-expression infix-expressions? )
14) -> myFunc ( & identifier infix-expressions? )
15) -> myFunc ( & ??? infix-expressions? )

???- cannot reach a production that will get us &s.a

Correction

Line 64 should read in-out-expression& expression

@amartini51 amartini51 added the Content issue A problem in with the book's prose, code, or figures label Oct 10, 2023
@amartini51 amartini51 linked a pull request Oct 10, 2023 that will close this issue
@amartini51
Copy link
Member

Thanks! This change looks like it's probably correct, but I'll need to find someone who can tech review to confirm this is exactly the expected behavior.

@sarahcantohyatt
Copy link
Contributor Author

No problem. Thanks for the reply!

amartini51 added a commit that referenced this issue Oct 20, 2023
The old grammar didn't allow things like f(&x.y) which are legal in
Swift. The new grammar allows a bunch of extra stuff -- literals,
closures, and conditional expressions -- but that's a better problem to
have.

See also #194, where we're discussing a more specific fix.

Fixes: #193 (partially)
@amartini51
Copy link
Member

Keeping this issue open while we discuss a better fix in #194

@amartini51 amartini51 reopened this Oct 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content issue A problem in with the book's prose, code, or figures
Projects
None yet
2 participants