I’m +1 for the proposal.

Context, in case it’s useful for anyone: My particular use case for generic 
subscripts is with my SwiftyUserDefaults library 
(https://github.com/radex/SwiftyUserDefaults 
<https://github.com/radex/SwiftyUserDefaults>), which allows users to access 
user defaults with a syntax like: `Defaults[.foo]` and `Defaults[.foo] = 20`, 
in a type-safe way. `.foo` refers to a `DefaultsKey<T>` object, where T is the 
type stored in the user defaults. Right now, I’m forced to define multiple 
subscripts to support the standard types of user defaults, but it takes a lot 
of boilerplate code. Generic subscripts would abstract this away (with a help 
of a protocol to mark which types are supported). There’s also no good way to 
allow nested types like `[String]` or `[String: [Int]]`.

Best,
— Radek

> On 19 Jan 2017, at 22:39, Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Hello Swift community,
> 
> The review of SE-0148 “Generic Subscripts" begins now and runs through 
> January 24, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md
>  
> <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-proposal.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 
> <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/0148-generic-subscripts.md
>  
> <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-proposal.md>
> Reply text
> 
> Other replies
>  <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>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 
> <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

Reply via email to