You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mattneub opened this issue
Jun 25, 2017
· 2 comments
Labels
bugA deviation from expected or documented behavior. Also: expected but undesirable behavior.compilerThe Swift compiler in itselffeatureA feature request or implementation
The first access is laz = "Greetings" but it causes `laz` to be first set to "Howdy" as a side effect because the lazy initializer runs. This seems wrong.
The text was updated successfully, but these errors were encountered:
Those side effects are exactly what concern me. If the first access is to set the variable, that is (or should be) the initialization. The (possibly expensive) initializer isn't needed.
Also there's a weird difference here; setting a `lazy var` instance variable doesn't run its initial value expression. To see that, run this variant of the above code:
So why should setting a global do so? You surely wouldn't argue that the language should be changed the other way, to make them both run their initializers when set?
So I've long regarded this behavior as a bug. I can see that fixing it might require passing through a decision-making process, but I'm not in any doubt that the current behavior is intuitively not what one would expect or want.
bugA deviation from expected or documented behavior. Also: expected but undesirable behavior.compilerThe Swift compiler in itselffeatureA feature request or implementation
Environment
Swift 4
Additional Detail from JIRA
md5: d81068550564c0bc0de8ac7c29afb91a
Issue Description:
The basic example is:
The first access is
laz = "Greetings"
but it causes `laz` to be first set to "Howdy" as a side effect because the lazy initializer runs. This seems wrong.The text was updated successfully, but these errors were encountered: