Where is the implementation of `dividedReportingOverflow`?

[lukasa (Cory Benfield)]

@xwu

Agree; I thought that was what I expressed in my line of argumentation? If not, that is what I mean :)

It was, but in my view it got lost somewhat in the back-and-forth regarding the constant propagation optimisation.

@Nevin

They should all compile, since they exercise defined behavior.

I can understand that position, but I don't agree with it. I'm with @xwu: writing code that is 100% going to fault but doesn't use one of the blessed ways to do that is not something I feel like we necessarily have to allow. Whether they exercise defined behaviour is neither here nor there: if the Swift team don't want you to be able to write fatalError in the form 42 / 0 then I'm fine with that being forbidden.

[Nevin]

From my perspective, an error should mean, “This is not valid Swift code.”

And a warning should mean, “This is technically valid Swift code, but it’s almost certainly not what you meant.”

[Jumhyn (Frederick Kellison-Linn)]

@Nevin

From my perspective, an error should mean, “This is not valid Swift code.”

This is somewhat tautological, since "valid Swift code" is in some sense defined by what swiftc accepts. IOW, raising a compiler error in these situations is the same as saying "arithmetic expressions which would unconditionally trap at runtime are not valid Swift code."