Hi Dmitri,
Thanks for the quick answer, I filed a bug here:
https://bugs.swift.org/browse/SR-1927
(Unfortunately, I don’t think I could write a patch myself)
Loïc
> On Jun 28, 2016, at 7:25 PM, Dmitri Gribenko wrote:
>
> On Tue, Jun 28, 2016 at 9:46 AM, Loïc Lecrenier
> wrote:
>> I think S
Hi swift-evolution 😊
String’s Views have a few odd properties that have bothered me for a while. I
initially did not bring it up because I thought a String redesign was coming.
But since Swift 3 will be released very soon—and with the recent focus on
breaking changes—I thought now might be a go
>
> What about the all lower case “associatedtype”? The underscore alternative of
> “associated_type” breaks existing language precedent. The camel case version
> (“associatedType”) does have language precedent, and I wonder if it wouldn’t
> be a better choice:
>
>dynamicType
>didSet
>
Hi James,
“guard" is not the opposite of “if”.
From the Swift book: “You use a guard statement to require that a condition
must be true in order for the code after the guard statement to be executed.”
So, unlike “unless”, a “guard" statement must provide an “early exit” in its
else clause (fat
Hi Drew,
Thanks for the review, just a quick remark:
“Real” type aliases are already forbidden inside protocols, so this proposal
wouldn’t change that.
(According to the grammar, a protocol body can only contain: property, method,
initializer, subscript, or associated type member declarations)
Agreed for requiredtype. But I am not convinced “associatedtype” belabors the
relationship between the protocol and the requirements.
The word “associated” is never used as a replacement for “requirement”. It just
names what the requirement is.
“[protocol] can only be used as a generic constrai
> Aren't we bikeshedding here? These are all good names; I think we can pick
> one, and leave the final choice to the core team.
Yes, we are :(
I was reluctant to start this thread, but I think it’s worse if the core team
has this debate during the review.
I promise I’ll choose a keyword before
I like placeholder too.
However, it also suffers from the lack of “type” in it.
So, the real comparison is between:
placeholder — associated
placholdertype — associatedtype
> On Dec 20, 2015, at 10:06 AM, Andrew Hoos wrote:
>
> I second placeholder as the most rational keyword. Every descripti
-1
I understand the idea. But we would still need a replacement for “typealias”
because “Element: typealias” says “Element is a type alias” and not “Element is
an associated type”.
Also, it would be difficult to add inheritance clauses and default values.
“Element is an associated type that con
Hi,
I’m starting a new thread for this proposal
https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
So far, everybody agreed that using distinct keywords for type alias and
associated type declarations is a good idea.
However, some people think th
10 matches
Mail list logo
