Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Dominik Pich via swift-evolution]

hello,
im not sure I like this. I think new cases to switches should always break an 
app. :)

> Am 19.12.2017 um 14:58 schrieb Ted Kremenek via swift-evolution 
> :
> 
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
> January 3, 2018.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>  
> 
> Reviews are an important part of the Swift evolution process. All review 
> feedback should be sent to the swift-evolution mailing list at:
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> When replying, please try to keep the proposal link at the top of the message:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>  
> 
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift.
> 
> When reviewing a proposal, here are some questions to consider:
> 
> What is your evaluation of the proposal?
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
> Does this proposal fit well with the feel and direction of Swift?
> 
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Dominik Pich via swift-evolution]

> What is your evaluation of the proposal?
+1

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

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
None .. but I know I like type safety

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A quick reading.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Dominik Pich via swift-evolution]

Very much in favour of this
 - access modifiers in swift became way to confusing.. and the usefulness is 
limited. Keep it simple I say. THAT benefits swift the most in the long run

Kind Regards
Dominik

Web: https://pich.info
Twitter: @DaijDjan
Facebook: Dominik.Pich

> On 22 Mar 2017, at 21:20, David Beck via swift-evolution 
>  wrote:
> 
> What is your evaluation of the proposal?
> Definitely in favor of this. About halfway through the Swift 3 migration I 
> gave up trying to think through where to use fileprivate and where to use 
> private and just did a project level find and replace to use fileprivate 
> everywhere. So far over the last year I haven't found a case where I want to 
> use private instead of fileprivate. The one time I thought it came up, when I 
> looked at it again I realized I really should be using 2 files anyway.
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Maybe. It certainly would remove confusion.
> 
> Does this proposal fit well with the feel and direction of Swift?
> Yes.
> 
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> I don't think I've ever seen a language distinguish private and fileprivate. 
> It seems like all other languages choose one behavior or the other, and stick 
> with it. Adding fileprivate seemed like Swift's attempt to make everyone 
> happy, when it wasn't needed.
> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> Read through the proposal.
> 
> On Mon, Mar 20, 2017 at 4:54 PM, Douglas Gregor via swift-evolution 
> > wrote:
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>  
> 
> Reply text
> Other replies
>  
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> 
> ___
> 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] Replace named returns with `out` parameters?

[Dominik Pich via swift-evolution]

Totally against out params. Returning tuples is way more logical & 
understandable

BR
Dominik

Web: https://pich.info
Twitter: @DaijDjan
Facebook: Dominik.Pich

> On 28 Dec 2016, at 15:06, Daniel Leping via swift-evolution 
>  wrote:
> 
> -1 here. What's wrong with tuples? Don't kill functional approach
> 
> On Wed, 28 Dec 2016 at 19:35 Micah Hainline via swift-evolution 
> > wrote:
> You haven't really explained what problem this solves, and it would have to 
> be a pretty big one to justify such a change.
> 
> I'm -1 on this, until a compelling argument is made. This feels like just 
> liking the syntax of another language and wanting it in Swift.
> 
> On Dec 28, 2016, at 5:09 AM, Anton Zhilin via swift-evolution 
> > wrote:
> 
>> Some people on the list wondered, why we have moved from tuples in function 
>> parameters, but multiple returns are still implemented using tuples? The 
>> following code still compiles:
>> 
>> 
>> 
>> func position() -> (x: Int, y: Int) {
>> 
>> return (x: 0, y: 0)
>> 
>> }
>> 
>> 
>> 
>> let (y, x) = position()
>> 
>> 
>> 
>> (Maybe it’s a bad example, because naturally we’d use Point struct. Let’s 
>> pretend those two parameters don’t make sense as a struct.)
>> 
>> 
>> 
>> What I want to discuss is if we should introduce out parameters and make 
>> them the default for multiple returns for Swift 4. The syntax would look 
>> like:
>> 
>> 
>> 
>> func position(x: out Int, y: out Int) {
>> 
>> x = 0
>> 
>> y = 0
>> 
>> }
>> 
>> 
>> 
>> var y
>> 
>> position(x: let x, y: y)
>> 
>> 
>> 
>> out arguments can be any patterns allowed on the left side of assignment, 
>> including wildcard pattern and tuple destructuring pattern.
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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

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

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

[Dominik Pich via swift-evolution]

I agree with karl. there is nothing really mathematical with min/max

e.g. find the longest sequence of characters in a string or the smallest array 
or the minimal x coordinate of view objects…
min/max/clamp are needed everywhere.

LG
Dominik

Web: https://pich.info
Twitter: @DaijDjan
Facebook: Dominik.Pich

> On Aug 31, 2016, at 3:53 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Comparable makes semantic guarantees about how values of conforming types 
> might be ordered. You don't need `min` or `max` for that to be useful, since 
> it's trivial to implement using comparison operators.
> 
> Basic numeric types require compiler magic and thus belong in the standard 
> library. Likewise, dictionaries have special syntactic sugar and have uses 
> for types that can guarantee comparable semantics. A decimal type, though, 
> can be implemented outside the standard library and probably would belong in 
> a math library. Likewise mathematical constants such as e. I think min and 
> max fall into the latter category.
> 
> On Wed, Aug 31, 2016 at 8:10 AM Karl  > wrote:
> 
> > On 30 Aug 2016, at 10:18, Xiaodi Wu via swift-evolution 
> > > wrote:
> >
> > As an additive proposal, I don't think this would be in scope for the 
> > current phase of Swift 4.
> >
> > Looking forward, though, I'm not sure this belongs in the standard library. 
> > In general, my understanding is that Swift's standard library is 
> > deliberately small, and that the criteria for additions are that it's 
> > widely used *and* also non-trivial for the user to write correctly. I've 
> > had to use clamping, obviously, but it's a trivial one-liner that is hard 
> > to write incorrectly. If anything, I'd be in favor of removing max and min 
> > into a future math library outside the standard library.
> 
> min & max (and clamping) are hardly “math” operations. They operate on 
> Comparables, so you can apply them to more abstract things than just numbers.
> 
> Otherwise, you might as well put Comparable and all standard numeric types 
> like Int and Float in a math library, too.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Re-Visit Proposal: Weak Native Swift Containers (12 2015)

[Dominik Pich via swift-evolution]

Hello,
I'd like to re-visit a proposal from Riley Testut about weak  
containers. Since no conclusion/outcome was achieved (AFAICS from  
looking at the archives and the repository)
and since I just would have needed this again too... I found it a good  
time to re-propose this :D


---

"
In multiple places in my projects, I essentially recreate the  
“multiple observer” pattern used by NSNotificationCenter. Originally  
this was implemented by simply maintaining an array of observers, and  
adding to/removing from it as necessary. However, this had the  
unintended side effect of maintaining a strong reference to the  
observers, which in many cases is undesirable (for the same reasons  
it’s common to mark delegate properties as weak).


Now, I’m using a private NSHashTable instance, and expose the  
observers as public API by creating a public computed property which  
essentially returns an array derived from the NSHashTable like so:


public var receivers: [GameControllerReceiverType] {
// self.privateReceivers.allObjects as!  
[GameControllerReceiverType] crashes Swift :(
return self.privateReceivers.allObjects.map({ $0 as!  
GameControllerReceiverType })

}

This workaround works, but is undesirable for a number of reasons.  
Most notably:


• NSHashTable is not a native Swift collection, and is also not in the  
Foundation Swift port, so it is not portable to other systems.
• It also has not yet been annotated with generics, so it loses the  
nice type safety of other Swift collections. Because of this, I have  
to map the objects to the appropriate type before returning the  
allObjects array, which runs in O(n) time instead of O(1).
• It’s repetitive. For every type that wants to implement this  
pattern, they must maintain both a public computed method and a  
private NSHashTable instance. This gets worse when this should be part  
of a protocol; there’s no way to enforce that each type conforming to  
it has a NSHashTable, while also keeping that information private from  
the consumer of the API.


I think native swift collections with support for weak references for  
their contents would be very useful, and in more places than just  
listed above. I don’t think Array could be easily extended to support  
it (what happens if a value is released? does everything shift down?  
do they keep their indices?), but Set and Dictionary (where the keys  
and/or values could be weak, akin to NSMapTable) would be good  
candidates IMO.


Thoughts?"

--reference to last message thread:  
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001579.html

(last messages were 'arguing' how to implement it)



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

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

[Dominik Pich via swift-evolution]

>> On May 10, 2016, at 3:30 PM, Tyler Cloutier via swift-evolution 
>>  wrote:
>> 
>> Secondly it’s a very simple way of introducing new programmers to loops. 
>> It’s IMHO more clear to a new programmer that repeat will just repeat 
>> indefinitely vs while true.
> 
> This point seems strange to me - why teach a new programmer about loops by 
> first showing them a looping construct they should probably never use in 
> actual practice until they really know what they’re doing?
totally agree… it would be a bad first introduction, id say :)

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

Re: [swift-evolution] [proposal] Allow function argument type to be omitted when passing a default value from which it can be inferred

[Dominik Pich via swift-evolution]

I think it would add consistence… everywhere else types can be inferred… why 
not here

> On May 10, 2016, at 12:02 PM, Sam Dods via swift-evolution 
>  wrote:
> 
> I propose that function argument types could be omitted in the same way as 
> variable and property argument types are omitted when they are set at point 
> of definition.
> 
> At present the type of properties and variables can be inferred as below:
> 
> class EvolutionManager {
>  let proposalManager = ProposalManager()   // type is inferred
> 
>  func proposeTopic(topic: String) {
>let evolution = Evolution(topic: topic) // type is inferred
>proposalManager.proposeEvolution(evolution)
>  }
> }
> 
> However, function arguments cannot be inferred, as below:
> 
> class EvolutionManager {
>  func proposeEvolution(evolution: Evolution, proposalManager = 
> ProposalManager()) {   // compiler error, cannot infer type
>proposalManager.proposeEvolution(evolution)
>  }
> }
> 
> It's a nice feature of the language that the type can be inferred for 
> properties and variables, so I don't see any reason not to allow the same for 
> function arguments. It allows for more concise code, and adds consistency 
> with other language features. And I don't personally think it would make our 
> code any harder to read.
> 
> There are of course some cases where the type cannot be inferred, i.e. when 
> the type should actually be a protocol type and the default value is a 
> concrete type. Consider the following:
> 
> protocol ProposalHandler {
>  associatedType P : Proposable
>  propose(p: P)
> }
> 
> class EvolutionManager {
>  // the type would be inferred as the concrete type `ProposalManager` and 
> could not be
>  // called with any other argument type that conforms to the 
> `ProposalHandler` protocol,
>  // as may have been the intention
>  func proposeEvolution(evolution: Evolution, proposalHandler = 
> ProposalManager())
> 
>  // instead it should be written as follows:
>  func proposeEvolution(evolution: Evolution, proposalHandler: ProposalHandler 
> = ProposalManager())
> }
> 
> But this is the same for properties and variables, so it should not be a 
> reason to not allow inferring of function arguments. For example:
> 
> class EvolutionManager {
>  // the property is inferred as the concrete type `ProposalManager` and may 
> not
>  // be set to any other value of type that conforms to the `ProposalHandler` 
> protocol,
>  // as may have been the intention.
>  var proposalHandler = ProposalManager()
> 
>  // instead it should be written as follows:
>  var proposalHandler: ProposalHandler = ProposalManager()
> }
> 
> What do people think of this?
> 
> It would have no impact on existing code, and it's not the kind of thing that 
> needs an alternative solution.
> 
> 
> ___
> 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] proposal for a even simpler guard.. => guard!

[Dominik Pich via swift-evolution]

;) yes. I know I can write let x = y! but IMHO THAT is too brief again. 
I like the fact that guard makes you look what you do… it is a little bit like 
assert(x != nil)

guard! let x = y

it reads awesome and everybody can more easily see it is a potentially fatal & 
important call

> On May 3, 2016, at 1:38 AM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> We have that; it’s just ‘!’. :-)
> 
> Jordan
> 
>> On May 2, 2016, at 12:09, Dominik Pich via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hello,
>> often the guard statement is used to only unwrap optionals. multiple guards 
>> will cause a lot of ‘overhead’.
>> also often if it doesn’t work. there is no easy way we can gracefully 
>> recover ;)
>> 
>> so how about we do the same as with try/catch where you can use try! and 
>> have a guard!
>> 
>> the guard! could just throw an exception …
>> 
>> regards
>> Dominik
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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] proposal for a even simpler guard.. => guard!

[Dominik Pich via swift-evolution]

yes. true. that’d be also totally fine.

my main issue is to make unwrapping easier ;)

> On May 2, 2016, at 9:57 PM, David Waite <da...@alkaline-solutions.com> wrote:
> 
> By existing semantics of the exclamation mark, ‘guard!' would be expected to 
> cause the application to fail fatally, not throw. This is the same as try!.
> 
> -DW
> 
>> On May 2, 2016, at 1:09 PM, Dominik Pich via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hello,
>> often the guard statement is used to only unwrap optionals. multiple guards 
>> will cause a lot of ‘overhead’.
>> also often if it doesn’t work. there is no easy way we can gracefully 
>> recover ;)
>> 
>> so how about we do the same as with try/catch where you can use try! and 
>> have a guard!
>> 
>> the guard! could just throw an exception …
>> 
>> regards
>> Dominik
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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] proposal for a even simpler guard.. => guard!

[Dominik Pich via swift-evolution]

Hello,
often the guard statement is used to only unwrap optionals. multiple guards 
will cause a lot of ‘overhead’.
also often if it doesn’t work. there is no easy way we can gracefully recover ;)

so how about we do the same as with try/catch where you can use try! and have a 
guard!

the guard! could just throw an exception …

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