cc @DougGregor

This is recursing infinitely, so it crashes when it runs out of stack space, just like

func f() { f() }
f()

Ah, so this is fully correct type-checking-wise, but it would be nice™ to warn on unconditional recursion, like Clang does.

I think maybe the warning should be different depending on the case.

• For methods or functions, there might be a case where recursion is necessary, so a warning on unconditional recursion should be shown.

• However, for initializers there is no scenario where calling the same initializer (not super) will not crash, so that should be a build error, IMHO.

That's not necessarily true; you could pass different arguments to it.

@belkadan In that case it would be a convenience initializer, I mean a normal non-convenience initializer.

Oh, good point. Designated initializers can't delegate. Okay, I'll un-dup your original bug.

No, wait, a struct initializer doesn't have to be marked convenience to do it.

In that case, the compiler should throw an error for non-convenience class initializers. It may be a small thing, be it makes the language safer. I had a property that I initialized in a class before init() (e.g. var property = Foo()). I spent 2 days debugging this in my code and tracking it down, since it would crash before arriving at init() it was hard to track. It may be a simple mistake, but in large codebases can lead to hard to track bugs.

It already does that:

class Test {
  init() {
    self.init()
  }
}

<stdin>:2:3: error: designated initializer for 'Test' cannot delegate (with 'self.init'); did you mean this to be a convenience initializer?
  init() {
  ^
  convenience 
<stdin>:3:10: note: delegation occurs here
    self.init()
         ^

Resolved by the merge of #11869.