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 caught for classes and not structs.

   -

   Is the problem being addressed significant enough to warrant a change to
   Swift?

Yes, focus is on getting rid of inconsistencies and problems.

   -

   Does this proposal fit well with the feel and direction of Swift?

Yes, Swift is meant to be consistent.

   -

   If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?

No

   -

   How much effort did you put into your review? A glance, a quick reading,
   or an in-depth study?

Glance

  -- Howard.

On 15 November 2017 at 08:24, Jordan Rose via swift-evolution <
swift-evolution@swift.org> 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-breaking change’ is something that can cause previously compiling
> code in another module to result in compile-time errors”?
>
> Thanks for pointing out the potential for confusion here!
> Jordan
>
>
> On Nov 14, 2017, at 12:55, David Hart <da...@hartbit.com> wrote:
>
> 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-breaking if I don’t write an explicit initializer with
> the same signature as the old automatic. Can something be done to clarify
> the proposal in that regard or is it too late?
>
> David.
>
> On 14 Nov 2017, at 20:31, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 Swift evolution process. All review
> feedback should be sent to the swift-evolution mailing list at:
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> When replying, please try to keep the proposal link at the top of the
> message:
>
> Proposal link: https://github.com/apple/swift-evolution/blob/
> master/proposals/0189-restrict-cross-module-struct-initializers.md
> ...
> Reply text
> ...
> Other replies
>
> What goes into a review of a proposal?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift.
>
> When reviewing a proposal, here are some questions to consider:
>
>    -
>
>    What is your evaluation of the proposal?
>    -
>
>    Is the problem being addressed significant enough to warrant a change
>    to Swift?
>    -
>
>    Does this proposal fit well with the feel and direction of Swift?
>    -
>
>    If you have used other languages or libraries with a similar feature,
>    how do you feel that this proposal compares to those?
>    -
>
>    How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
>
> Thanks,
> Ted Kremenek
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to