> What is your evaluation of the proposal?
>
It makes total sense. It’s a hole to plug in the resilience story.
> Is the problem being addressed significant enough to warrant a change to
> Swift?
>
Yes.
> Does this proposal fit well with the feel and direction of Swift?
>
It feels very Swift b
> On 14 Nov 2017, at 22:24, Jordan Rose wrote:
>
> Hi, David. This only affects cross-module use cases, which means that the
> automatically synthesized initializer doesn’t come into play (because it’s
> not public). Is the clarification you’re looking for something like “a
> 'source-breakin
The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/
proposals/0189-restrict-cross-module-struct-initializers.md
-
What is your evaluation of the proposal?
+1, more an oversight in the original design rather than a change. Funny
how this problem was caug
Hi, David. This only affects cross-module use cases, which means that the
automatically synthesized initializer doesn’t come into play (because it’s not
public). Is the clarification you’re looking for something like “a
'source-breaking change’ is something that can cause previously compiling co
I was initially quite confused about the proposal's first sentence: "Adding a
property to a public struct in Swift ought to not be a source-breaking change.”
Because I nearly always rely (like many developers) on struct automatic
initializers, adding a property is pretty much always a source-bre
The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now
and runs through November 21, 2017.
The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
Reviews are an important part of the
