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

[SR-10931] Optional initialization inconsistent between Optional<T> vs T? #53322

Open
masters3d opened this issue Jun 14, 2019 · 2 comments
Open
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@masters3d
Copy link
Contributor

Previous ID SR-10931
Radar None
Original Reporter @masters3d
Type Bug
Environment

swift 5.0

Additional Detail from JIRA
Votes 2
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: 0e6cd4419cd22cf69c97288a90ec7e94

relates to:

  • SR-354 Non-optional variable tuple of optional values should not have default value
  • SR-801 TestPOUnwrapping.py - PO for optional class members set to nil are showing up as if 0 or ""
  • SR-11768 Stored property declaration + initialization expressions cannot be inlinable
  • SR-11777 'var something: 'Type?' always get double initialised

Issue Description:

I am having a hard time understanding why T? variables auto initialize to nil when Optional<T> variables do not. This seems like a bug to me. If its not a bug, where else is this feature being used?

do{ 
let someValue1:Optional<String> 
//print(someValue1) // error: constant 'someValue1' used before being initialized 
var someValue11:Optional<String> 
// print(someValue11) // error: variable 'someValue11' used before being initialized 
let someValue2:String? 
// print(someValue2) //error: constant 'someValue2' used before being initialized 
var someValue22:String? 
print(someValue22) // Compiler happy. Why? What is the technical reason why this should work. 

// Now consider the following type of optional. 
var someValue33:String!
print(someValue33 + "") // Boom Crash. Implicit initialization here is actually dangerous. 
}
@belkadan
Copy link
Contributor

@slavapestov, you have the dup for this, right?

@slavapestov
Copy link
Member

I'm not quite sure we consider this a bug, although to be honest I think it's confusing too. @DougGregor can you chime in? IIRC, the 'has default nil value' check happens before type resolution, so we implement it as a structural property of the syntax itself. Should we try to change things around to nil-initialize Optional<T>, typealiases to Optional, etc, or is there a non-implementation-centric motivation for the current behavior?

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

3 participants