Re: [swift-evolution] Questions about non-exhaustive enums

[Lance Parker via swift-evolution]

This is the same issue as when a library maintainer changes a class from open 
to closed.

> On Jan 5, 2018, at 10:54 AM, Ignacio Soto via swift-evolution 
>  wrote:
> 
> I love the revision to the proposal 
> , but I have a couple of 
> remaining questions that don't seem to be addressed in the doc and I'm 
> curious about:
> What happens if a library maintainer adds a new case to a @frozen enum?
> What happens if a library maintainer changes an enum from @frozen to 
> non-frozen?
> Thanks!
> 
> 
> -- 
> Ignacio Soto
> ___
> 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] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Lance Parker via swift-evolution]

I dislike `mapSome` because, to me, it implies it will only pass the non-nil 
values of the sequence to the transformation closure.

`compactMap` isn’t an intuitive name, but I could get used to it. The thing I 
like about it is it could be paired with a `compacted` method that removes nils 
from the Sequence of optionals and returns a Sequence of non-optionals. If 
`compacted` is something that makes sense, then it would be nice if 
`compactMap` was just a merger of `map` and `compacted`. I would prefer to find 
a word other than compact that we could use here but I haven’t thought of one 
yet.

In isolation, I think that `filterMap` is best. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Lance Parker via swift-evolution]

The idea is that renaming this will nudge people into using map when 
appropriate.

> On Nov 9, 2017, at 1:45 PM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> - 1 I agree with Kevin Ballard. 
> 
> I think that it would be appropriate to nudge the user to use map instead. 
> 
> We already nudge people to use let over var so I think is sensible to do the 
> same for misuses of flatMap when map is sufficient.
> 
> Thanks!
> 
> 
>> On Nov 8, 2017, at 10:43 AM, John McCall via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Nov 8, 2017, at 1:20 PM, Kevin Ballard >> > wrote:
>>> 
>>> On Tue, Nov 7, 2017, at 09:37 PM, John McCall wrote:
 
> On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>>  
>> 
>> 
>> • What is your evaluation of the proposal?
> 
> This proposal is going to cause an insane amount of code churn. The 
> proposal suggests this overload of flatMap is used "in certain 
> circumstances", but in my experience it's more like 99% of all flatMaps 
> on sequences are to deal with optionals, not to flatten nested sequences.
> 
>> • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> I don't think so. It's a fairly minor issue, one that really only affects 
> new Swift programmers anyway rather than all users, and it will cause far 
> too much code churn to be worthwhile.
> 
> I'd much rather see a proposal to add a new @available type, something 
> like 'warning', that lets you attach an arbitrary warning message to a 
> call (which you can kind of do with 'deprecated' except that makes the 
> warning message claim the API is deprecated).
 
 As review manager, I generally try to avoid commenting on threads, but I 
 find this point interesting in a way that, if you don't mind, I'd like to 
 explore.
 
 Would this attribute not be a form of deprecation?  Certainly it acts to 
 discourage current and subsequent use, since every such use will evoke a 
 warning.
 
 Is the word "deprecation" just too strong?  Often we think of deprecated 
 APIs as being ones with more functional problems, like an inability to 
 report errors, or semantics that must have seemed like a good idea at the 
 time.  Here it's just that the API has a name we don't like, and perhaps 
 "deprecation" feels unnecessarily judgmental.
>>> 
>>> What I'm suggesting is that we don't change the API name at all. That's why 
>>> I don't want to use 'deprecated', because we're not actually deprecating 
>>> something. I'm just suggesting an alternative way of flagging cases where 
>>> the user tries to use flatMap but accidentally invokes optional hoisting, 
>>> and that's by making a new overload of flatMap that works for non-optional 
>>> (non-sequence) values and warns the user that what they're doing is better 
>>> done as a map. Using the 'deprecated' attribute for this would be confusing 
>>> because it would make it sound like flatMap itself is deprecated when it's 
>>> not.
>> 
>> I see.  Thanks.
>> 
>> John.
>> 
>>> 
 Also, more practically, it conflates a relatively unimportant suggestion — 
 that we should call the new method in order to make our code clearer — 
 with a more serious one — that we should revise our code to stop using a 
 problematic API.  Yes, the rename has a fix-it, but still: to the extent 
 that these things demand limited attention from the programmer, that 
 attention should clearly be focused on the latter set of problems.  
 Perhaps that sense of severity is something that an IDE should take into 
 consideration when reporting problems.
 
 What else would you have in mind for this warning?
>>> 
>>> The main use for this warning would be for adding overloads to methods that 
>>> take optionals in order to catch the cases where people invoke optional 
>>> hoisting, so we can tell them that there's a better way to handle it if 
>>> they don't have an optional. flatMap vs map is the obvious example, but I'm 
>>> sure there are other cases where we can do this too.
>>> 
>>> But there are also other once-off uses. For example, in the past I've 
>>> written a function that should only ever be used for debugging, so I marked 
>>> it as deprecated with a message saying 'remove this before committing your 
>>> code'. This warning would have been better done using the new 'warning' 
>>> attribute instead of as a deprecation notice.
>>> 
>>> -Kevin Ballard
>>> 
 John.
 
> With that sort of thing we could

Re: [swift-evolution] Abstract methods

[Lance Parker via swift-evolution]

How would a class partially implement a protocol? That’s a compile error.

> On Nov 2, 2017, at 2:30 PM, C. Keith Ray via swift-evolution 
>  wrote:
> 
> If a class partially implemented a protocol, it also would not be 
> instantiatable, but a subclass can supply the missing method(s). Doesn’t the 
> compiler already handle that? How are abstract classes harder?
> 
> C. Keith Ray
> https://leanpub.com/wepntk  <- buy my book?
> http://agilesolutionspace.blogspot.com/ 
> 
> twitter: @ckeithray
> http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf 
> 
> 
> On Nov 2, 2017, at 2:22 PM, Slava Pestov  > wrote:
> 
>> Abstract methods and classes seem like they will introduce a fair amount of 
>> complexity in the type checker, particularly around metatypes and 
>> constructors, because now we have this new concept of a class that cannot be 
>> directly instantiated. I’m not sure the cost is worth the benefit.
>> 
>> Slava
>> 
>>> On Nov 2, 2017, at 12:45 PM, C. Keith Ray via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> How many "subclass must override" assertions or comments in base class 
>>> methods do we need to see, to want to add "abstract" to the Swift language? 
>>> 5? 50? 500?
>>> 
>>> It's a not uncommon idiom in Objective-C.
>>> 
>>> I'm about to port a substantial amount of C++ code to swift, and compiler 
>>> help to enforce abstract classes would be very useful.
>>> 
>>> 
>>> --
>>> C. Keith Ray
>>> Senior Software Engineer / Trainer / Agile Coach
>>> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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