This diagnostic logic (error: found an unexpected second identifier in variable declaration; is there an accidental break?) should not be invoked if the second identifier or _ token is at a new line.

Mmm, I’m not certain on whether it should be valid syntax. Declaring a variable has always required either an explicit type annotation or an assignment, and this has neither. Certainly I see the point that the wrapper type has left no ambiguity regarding either the type or the initial value here, but we don’t allow users to omit everything to the fullest extent that it can be inferred (for example, in declarations, we always require explicit type annotations): this is a judgment call that has to balance readability and other considerations.

But more to the point, whatever your feeling on the question of “should,” unless I'm mistaken, the compiler is correct that it isn’t valid syntax today. Changing that would require a Swift Evolution proposal, and we could debate then whether it should be allowed, but I don’t think it’s just a starter bug to be fixed. The diagnostic could always be improved though, and the compiler could certainly volunteer here to fill in “= 1”.

I mean the point is not "@Wrap var val;" should be valid or not.

@propertyWrapper
struct Wrap {
  var wrappedValue: Int = 1
}
func test() {
  @Wrap var val
}

This is actually accepted in current Swift5.5.

The point is, if "@Wrap var val;" is valid,

func test() {
  @Wrap var val
  _ = val
}

should be accepted as well because there's no ambiguity here.

Ah, thanks. I wasn’t aware of that. It makes sense that if the first line is accepted on its own, so should the example above. 🙂

Comment by Nhat Dinh (JIRA)

@rintaro interesting issue. Since no one is assigned yet. I assigned myself. Will work on this after finishing setting up my local environment. One question, what code version or tag is appropriate for reproducing this issue?

Duplicate of #57542