Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Janosch Hildebrand via swift-evolution]

> On 03 Jan 2016, at 07:38, Douglas Gregor  wrote:
> 
>   * What is your evaluation of the proposal?

I am in favor of this for the same reasons mentioned by the previous reviewers.

>   * 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?

I think so. 

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

I am only aware of Rust and I haven't used that enough to make any meaningful 
comparisons.

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

I read the proposal and followed the previous threads discussing the proposal 
and the keyword.

Speaking of which, `associatedtype` remains my favorite. I don't think its 
ideal but I prefer it to the alternatives that were considered.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
>   Cheers,
>   Doug Gregor
>   Review Manager
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

- Janosch

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: Proposed rewrite of Unmanaged

[Janosch Hildebrand via swift-evolution]

I like "transfer" but I think this would be mostly helpful to people familiar 
with manual ref. counting in Obj-C.
It's probably just as confusing to others and the visual similarity could be 
confusing as well (like with `Unmanaged`).

But I also wouldn't be opposed to these if they were selected...


> On 20 Dec 2015, at 06:56, Félix Cloutier via swift-evolution 
>  wrote:
> 
> There's still the "release" issue (std::unique_ptr::release versus -[NSObject 
> release]), but "transfer" seems like a good word to me. What about 
> "transferByRetaining" and "transferWithoutRetaining"?
> 
> Félix
> 
>> Le 20 déc. 2015 à 00:01:22, Nevin Brackett-Rozinsky via swift-evolution 
>> > a écrit :
>> 
>> Floating an idea here—not sure if it’s even in the right ballpark, and I’m 
>> certainly not tied to the specific wording, but what about something along 
>> the lines of:
>> 
>> .transferByReleasing()
>> .transferWithoutReleasing()  // or perhaps just .transfer()
>> 
>> Or the slightly-more-verbose:
>> 
>> .transferObjectByReleasingReference()
>> .transferObjectWithoutReleasingReference()// or .transferObject()
>> 
>> Nevin

- Janosch

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

[Janosch Hildebrand via swift-evolution]

I am also strongly in favor of this proposal.

There are probably enough valid use cases for a @suppress_unused_warning but 
personally I don't think pop() is a great example.

I think a second method à la dropFirst/Last/... that returns Void would be 
better at communicating intent and allows pop() to retain the warning.

- Janosch

> On 18 Dec 2015, at 21:48, Erica Sadun via swift-evolution 
>  wrote:
> 
> I vote +1 in favor of making warn_unused_result the default. It's simple, 
> elegant, logical, functional, and will reduce stdlib clutter.
> 
> As for replacing it? Although I'd probably be okay with 
> suppress_unused_warning, please consider optional 
> hey_no_worries_mate_on_unused, unused_is_mellow, or dont_harsh_my_unused. 
> Supporting _ = pop() without further warning is icing on the cake, as it 
> enables the behavior to be established at either the API or consuming end.
> 
> -- E
> 
>> On Dec 18, 2015, at 1:25 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>>> On Dec 18, 2015, at 3:47 AM, Tino Heth via swift-evolution 
>>> > wrote:
>>> 
 _ = pop()
>>> 
>>> Now that's what I'd call ugly - I vote against everything that forces me to 
>>> use more underscores ;-)
>> 
>> “pop()” is an example of the comparatively-rare method that one might want 
>> to annotate to avoid the warning: the side-effect is useful even if you’re 
>> dropping the result.  We’re only talking about making warn_unused_result the 
>> default, not making it the only option.
>> 
>> -Dave
>> 
>> ___
>> 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

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

[Janosch Hildebrand via swift-evolution]

> On 18 Dec 2015, at 23:23, Dave Abrahams  wrote:
>> 
>> I think a second method à la dropFirst/Last/... that returns Void would be 
>> better at communicating intent and allows pop() to retain the warning.
> 
> Those are non-mutating methods that don’t return Void, FWIW.  Names to be 
> adjusted accordingly… ;-)

Fair point :-)


>>> On 18 Dec 2015, at 21:48, Erica Sadun via swift-evolution 
>>> > wrote:
>>> 
>>> I vote +1 in favor of making warn_unused_result the default. It's simple, 
>>> elegant, logical, functional, and will reduce stdlib clutter.
>>> 
>>> As for replacing it? Although I'd probably be okay with 
>>> suppress_unused_warning, please consider optional 
>>> hey_no_worries_mate_on_unused, unused_is_mellow, or dont_harsh_my_unused. 
>>> Supporting _ = pop() without further warning is icing on the cake, as it 
>>> enables the behavior to be established at either the API or consuming end.
>>> 
>>> -- E
>>> 
 On Dec 18, 2015, at 1:25 PM, Dave Abrahams via swift-evolution 
 > wrote:
 
> On Dec 18, 2015, at 3:47 AM, Tino Heth via swift-evolution 
> > wrote:
> 
>> _ = pop()
> 
> Now that's what I'd call ugly - I vote against everything that forces me 
> to use more underscores ;-)
 
 “pop()” is an example of the comparatively-rare method that one might want 
 to annotate to avoid the warning: the side-effect is useful even if you’re 
 dropping the result.  We’re only talking about making warn_unused_result 
 the default, not making it the only option.
 
 -Dave
 
 ___
 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 
>> 
> -Dave

- Janosch

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: Proposed rewrite of Unmanaged

[Janosch Hildebrand via swift-evolution]

I like `UnsafeReference` as the new name of the type and I think the basic API 
is clearer than with `Unmanaged`.
The initializers are much better than the static methods and 
`take(Un)RetainedValue()` were certainly less than ideal method names.


> On 18 Dec 2015, at 02:37, Dave Abrahams via swift-evolution 
>  wrote:
> The name of the release() method has been contentious.

This is a hard one. I don't particularly like `release()` for this but I can't 
really think of anything better either.
I think it's descriptive which is good but it will take some getting used to as 
the "consuming" method although the documentation is pretty clear about the 
semantics which is helpful.

The `.releaseAndReturnObject` proposed by TJ feels a bit clearer but is also a 
lot more verbose.
Also I don't think it would make anything clearer if I didn't already know 
about the manual memory management terminology.
And something along these lines would also be bit more awkward to use if the 
return values were then discarded, although the proposed `manuallyRelease()` 
would take care of that...

> We’re not sure about the terminology 
> 
>  (Unretained/Retained/Released) used to precisely describe the semantics of 
> UnsafeReference. We’d like to know if these terms make sense to you or 
> whether you have better ideas.

Coming from Objective-C I find it makes sense. I also don't think the 
terminology is a big issue here. If you know the concepts you're probably able 
to map them to these terms and the documentation seems helpful in that case.

If, on the other hand, you are not familiar with manual reference counting 
concepts I doubt this will be very helpful.
But I don't think that can be solved with different terminology but instead 
requires more extensive documentation.
However I don't think the documentation for `UnsafeReference` is the place to 
try to explain the whole concept and this is more of a topic for `The Swift 
Programming Language` or a separate (advanced) tutorial or guide.

I like that the documentation tries to lay out a clear path to follow if you 
just want to get an object out of some un-annotated CF API but I can't really 
personally judge how well that works for a novice.


One other approach to terminology that comes to mind would be to focus more on 
the transfer of ownership into ARC as opposed to out of MRC.
Personally I often reason in that direction when thinking about the topic but I 
can't see a way in which it would be helpful for the documentation or method 
names...


> We want to know whether the usage pattern recommended above works for you.

For interacting with un-annotated CF APIs: Yes.

> We want to know if the API is sufficiently broad or if there are things you 
> currently get—and need—from Unmanaged that we’ve left out.

> On 18 Dec 2015, at 03:05, Joe Groff via swift-evolution 
>  wrote:
> - `Unmanaged` has also been promoted as a solution for people who need to do 
> manual reference counting, for performance or other reasons, so I think we 
> might want to keep the 'retain()' method. Conveniently enough, 
> `release()`-ing and dropping the return value would have the net effect of 
> decrementing the refcount by one, though the admonitions about the 
> `UnsafeReference` become invalid after that point wouldn't hold if you're 
> using `release()` purely for that effect, so maybe 
> `manuallyRetain()`/`manuallyRelease()` would be more appropriate for manual 
> refcounting applications.

As Joe mentioned, `Unmanaged` has a use for manual ref counting beyond 
immediate transfer from un-annotated APIs. 

I have used it for performance reasons myself (~ twice) and while I think it's 
a pretty small use case there isn't really any alternative.
If it would help I can also describe my use-cases in more detail.

I don't think this use case even needs to be described in the documentation for 
`UnsafeReference` and it's fine if its use is very much discouraged.

Personally I prefer the proposed `manuallyRetain()`/`manuallyRelease()` over 
plain `retain()`/`release()` as it clearly separates the returning and more 
generally applicable `release()` from the MRC methods. `retain()` would 
probably also have to return the object which would interfere with the max safe 
usage pattern.


> On 18 Dec 2015, at 03:05, Joe Groff via swift-evolution 
>  wrote:
> 
> - The `bitPattern:` constructors should be between UnsafeReference and 
> Unsafe[Mutable]Pointer, not COpaquePointer. Let COpaquePointer retire 
> gracefully.

Very much agreed.

- Janosch

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution