> On Jun 24, 2016, at 3:00 PM, Haravikk via swift-evolution
> wrote:
>for colinearSegment in remainingSegments where
> colinearSegment.angle.isEssentially(angle: segment.angle) { // Is parameter
> name even necessary?
My terminology sucks because I don’t
What is your evaluation of the proposal?
Strong yes.
Is the problem being addressed significant enough to warrant a change to Swift?
At Delicious we wrote a huge ugly macro set to define properties in a special
way so we could make key paths safely:
// Declares a safe-KVC-accessible property
Are “forceUnwrapping” and “withoutUnwrapping” special keywords here or are they
just there to try to explain what you’re doing? Because I was very confused by
them.
-Wil___
swift-evolution mailing list
swift-evolution@swift.org
On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution
wrote:
> When I see an IUO property, I consider it a sort of “contract”–it’s basically
> saying something like “I can’t set this to a valid value right now, but by
> the time you use it I promise that it’s
I’m curious about this statement at the end in "alternatives":
> The proposed design eliminates the problem of calling an API (without knowing
> it is async) and getting a Future back instead of the expected T result
> type. C# addresses this by suggesting that all async methods have their name
I think the comments on “prettify()” are from an earlier version of the sample
code? The way it’s called it doesn’t look like it’d access theList at all.
actor TableModel {
let mainActor : TheMainActor
var theList : [String] = [] {
didSet {
Oh, I see that this is addressed in the “ x = await (await foo()).bar()”
example. That IS ugly.
-W___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution