[SR-8172] (T) Reported as Single-Element Tuple Rather Than T #50704
Labels
bug
A deviation from expected or documented behavior. Also: expected but undesirable behavior.
good first issue
Good for newcomers
Attachment: Download
Environment
Xcode 10 Beta
Swift 4.2
Additional Detail from JIRA
md5: cc8906ad455bcb2e5245f0bf038e8a91
Issue Description:
When the type of a value is declared with organizational parentheses around the type name (or the value), Xcode's Quick Help reports the type as if it is a single-element tuple type. This reporting is confusing to users. It gives the impression that single-element tuples are allowed.
MINIMAL EXAMPLES:
In the examples, above, the values are both of type Int. The parentheses surrounding Int are meaningless formatting parentheses. For purposes of representation to the user, the type should be reported as being a plain Int, without the parentheses.
BUG: Xcode's Quick Help reports the type declaration of each as (Int), a single-element tuple–something that does not currently exist in the Swift language. See the screenshot, below.
EVALUATION: I understand that, under the hood, the compiler utilizes single-element tuples, and generally guards against allowing that implementation detail to leak out to the user. I believe this bug to be an example of leakage.
In this case, the bug is (I'm guessing) more an issue of how Xcode populates the Quick Help interface, rather than an issue that can be addressed from the compiler side. Yet, this bug is rooted in the parser and type checker, where the type is managed as an (Int) rather than an Int.
QUESTIONS: Is it necessary for the compiler to internally utilize single-element tuples? What is the purpose of an unlabelled single-element tuple? Would it be preferable for the internal compiler model to better align with the external model implemented by the user?
MORE DATA: The post-type-checking state of the AST for Example #2 is set forth, below.
QUICK HELP FOR EXAMPLE #1:
AST FOR EXAMPLE #2:
{panel:title=let b = (42)}
(source_file
(top_level_code_decl
))
(var_decl "b" type='(Int)' interface type='(Int)' access=internal let storage_kind=stored))
The text was updated successfully, but these errors were encountered: