Hi Keith,
As a small aside, I’d suggest using ObjectIdentifier instead of a String to
back your TypeRepresentation struct. ObjectIdentifier is Hashable and it has an
initializer that accepts any type. The benefit of your TypeRepresentation type
over ObjectIdentifier is that you can restrict the
Hehe :-)
I’ll hold off suggestions until we need to cross that road!
- Alex
> On Mar 15, 2016, at 6:28 PM, Arnold wrote:
>
> Hi Alex,
>
> Probably not, The name is a strawman. I guess I could not resist the
> optimizer speak after all. The programmer is asserting he guarantees the
> lifetim
Hi Arnold,
This seems like a great optimization tool. The only question I have is about
the method name. With the name `withUnsafeGuaranteedValue` we’re moving the
term “guaranteed” into API in addition to it being an implementation detail of
the compiler as far as I could tell. Is “guaranteed"
I think instead of an attribute I’d prefer rules that allow trailing closures
at call sites. The most straightforward solution would be to only allow using
trailing closures at the call site if the invoked function has a single closure
that’s the last parameter. I think the only unfortunate aspe
> * What is your evaluation of the proposal?
I think the proposal is great. The only thing I’d prefer is to use `associated`
over `associatedtype`.
`associated` has always felt better to me over `associatedtype`. It was
mentioned in one of the original proposals as the keyword that was initiall
> On Dec 28, 2015, at 10:24 AM, Stephen Celis wrote:
>
>> On Dec 28, 2015, at 11:47 AM, Alex Migicovsky via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>> On Dec 27, 2015, at 1:32 PM, Joe Groff via swift-evolution
>>> mailto:swift-
> On Dec 27, 2015, at 1:32 PM, Joe Groff via swift-evolution
> wrote:
>
> Some more things to consider:
>
> - Our naming conventions encourage the first parameter to most methods to be
> unlabeled, so unlabeled parameters come up a lot. I don't think there's a
> grammatical requirement for a
