Re: [swift-evolution] [Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop

[Hans Huck via swift-evolution]

> You may want to take a peek here: 
> https://gist.github.com/erica/a51a981ee0352235204692affa959307
>  
> -- E
>

Thanks for the link, Erica, very informative. The striding(by:) method combined 
with the (as of yet) non-canonical range types looks great; it also tackles 
half the problem, since it makes the use of reverse() no longer required in 
For-loops.

However, my main point remains unresolved, because

for i in (1...10).striding(by: -3)

is simply not as concise, readable, intuitive or elegant as

for i in 1...10 by -3

The "by" keyword is specifically meant to be syntactic sugar for the 
For-In-loop, and, as Vladimir pointed out, can easily be mapped onto the new 
striding() construct internally.

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

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

[Eugene Gubin via swift-evolution]

I like this idea. I think, if we could use `self` to access instance of
self, we should be allowed to use `Self` to access type of self.

2016-04-14 8:46 GMT+04:00 William Dillon via swift-evolution <
swift-evolution@swift.org>:

> This would be great!
>
> I use a nearly identical pattern in my networking framework that would be
> nice to streamline:
>
> public func ==(lhs: NetworkAddress, rhs: NetworkAddress) -> Bool {
> // Only addresses of the same protocol are considered equal.
> guard lhs.dynamicType == rhs.dynamicType else {
> return false
> }
>
>
> if lhs.dynamicType == IPv4NetworkAddress.self {
> return (lhs as! IPv4NetworkAddress) == (rhs as! IPv4NetworkAddress
> )
> }
>
> if lhs.dynamicType == IPv6NetworkAddress.self {
> return (lhs as! IPv6NetworkAddress) == (rhs as! IPv6NetworkAddress
> )
> }
>
>
> return false
> }
>
> - Will
>
> On Apr 13, 2016, at 6:41 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It's been pitched before, but I don't think we've had a dedicated thread
> to this idea. Erica has proposed making `Self` generally available within
> methods in types to refer to the dynamic type of the current receiver. One
> could think of `Self` as a special associated type member that exists in
> every type for this purpose. This also happens to be what you get when ask
> for the `dynamicType` member of a value. We could unify these concepts and
> get rid of the clunky `dynamicType` keyword, replacing it with `x.Self`.
>
> There's another benefit to this syntax change. Looking to the future, one
> of the many features Doug pitched in his generics manifesto was to
> generalize protocol existentials, lifting our current restrictions on
> protocols "with Self or associated types" and allowing them to be used as
> dynamic types in addition to static generic constraints. Once you do this,
> you often want to "open" the type of the existential, so that you can refer
> to its Self and associated types in the types of other values. I think a
> natural way would be to let you directly use Self and associated type
> members of existentials as types themselves, for example:
>
> let a: Equatable = /*...*/
> let b: Equatable = /*...*/
>
> // This is not allowed, since Equatable requires two values with the same
> static type, but
> // a and b may have different dynamic types.
> a == b
>
> // However, we can dynamically cast one to the other's dynamic type:
> if let bAsA = b as? a.Self {
> return a == bAsA
> }
>
> let x: RangeReplaceableCollection = /*...*/
> let y: Collection = /*...*/
>
> // If y has the same dynamic Element type as x, append it to x
> var z: x.Self = x
> if let yAsX = y as? Any {
> z.append(yAsX)
> }
>
> `x.Self` then becomes just the first step in this direction.
>
> -Joe
> ___
> 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] [Pitch] Rename `x.dynamicType` to `x.Self`

[William Dillon via swift-evolution]

This would be great!

I use a nearly identical pattern in my networking framework that would be nice 
to streamline:

public func ==(lhs: NetworkAddress, rhs: NetworkAddress) -> Bool {
// Only addresses of the same protocol are considered equal.
guard lhs.dynamicType == rhs.dynamicType else {
return false
}

if lhs.dynamicType == IPv4NetworkAddress.self {
return (lhs as! IPv4NetworkAddress) == (rhs as! IPv4NetworkAddress)
}

if lhs.dynamicType == IPv6NetworkAddress.self {
return (lhs as! IPv6NetworkAddress) == (rhs as! IPv6NetworkAddress)
}

return false
}

- Will

> On Apr 13, 2016, at 6:41 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> It's been pitched before, but I don't think we've had a dedicated thread to 
> this idea. Erica has proposed making `Self` generally available within 
> methods in types to refer to the dynamic type of the current receiver. One 
> could think of `Self` as a special associated type member that exists in 
> every type for this purpose. This also happens to be what you get when ask 
> for the `dynamicType` member of a value. We could unify these concepts and 
> get rid of the clunky `dynamicType` keyword, replacing it with `x.Self`.
> 
> There's another benefit to this syntax change. Looking to the future, one of 
> the many features Doug pitched in his generics manifesto was to generalize 
> protocol existentials, lifting our current restrictions on protocols "with 
> Self or associated types" and allowing them to be used as dynamic types in 
> addition to static generic constraints. Once you do this, you often want to 
> "open" the type of the existential, so that you can refer to its Self and 
> associated types in the types of other values. I think a natural way would be 
> to let you directly use Self and associated type members of existentials as 
> types themselves, for example:
> 
>   let a: Equatable = /*...*/
>   let b: Equatable = /*...*/
> 
>   // This is not allowed, since Equatable requires two values with the 
> same static type, but
>   // a and b may have different dynamic types.
>   a == b 
> 
>   // However, we can dynamically cast one to the other's dynamic type:
>   if let bAsA = b as? a.Self {
>   return a == bAsA
>   }
> 
>   let x: RangeReplaceableCollection = /*...*/
>   let y: Collection = /*...*/
> 
>   // If y has the same dynamic Element type as x, append it to x
>   var z: x.Self = x
>   if let yAsX = y as? Any {
>   z.append(yAsX)
>   }
> 
> `x.Self` then becomes just the first step in this direction.
> 
> -Joe
> ___
> 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] Crypto routines as part of the core library

[Travis Beech via swift-evolution]

So what would it take to get a standard set of crypto API's built into the 
language?

Travis Beech  |  Principal Developer  |  Unwired Revolution  |  c: 1 (209) 
535-5357
Optimizing Operations for Mobile and Distributed Systems

On Apr 13, 2016, at 10:11 AM, David Waite 
> wrote:

I don't know if we need a boost-like parent project in order to start building 
core code to be brought for inclusion.

I think success will naturally bring such a project structure - people seeking 
a curated and integrated set of frameworks to get common functionality.

-DW

On Apr 13, 2016, at 12:16 PM, Tino Heth via swift-evolution 
> wrote:

This seems like a great candidate for a library that could be developed in the 
community and then possibly brought into Corelibs in a future version
true - but sadly, there seems to be either no interest or manpower for a 
boost-like infrastructure...
Like many other fundamental topics, I don't think crypto belongs to the stdlib, 
but none the less, there should be a standard library for encryption/hashing.
___

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

[swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

[Joe Groff via swift-evolution]

It's been pitched before, but I don't think we've had a dedicated thread to 
this idea. Erica has proposed making `Self` generally available within methods 
in types to refer to the dynamic type of the current receiver. One could think 
of `Self` as a special associated type member that exists in every type for 
this purpose. This also happens to be what you get when ask for the 
`dynamicType` member of a value. We could unify these concepts and get rid of 
the clunky `dynamicType` keyword, replacing it with `x.Self`.

There's another benefit to this syntax change. Looking to the future, one of 
the many features Doug pitched in his generics manifesto was to generalize 
protocol existentials, lifting our current restrictions on protocols "with Self 
or associated types" and allowing them to be used as dynamic types in addition 
to static generic constraints. Once you do this, you often want to "open" the 
type of the existential, so that you can refer to its Self and associated types 
in the types of other values. I think a natural way would be to let you 
directly use Self and associated type members of existentials as types 
themselves, for example:

let a: Equatable = /*...*/
let b: Equatable = /*...*/

// This is not allowed, since Equatable requires two values with the 
same static type, but
// a and b may have different dynamic types.
a == b 

// However, we can dynamically cast one to the other's dynamic type:
if let bAsA = b as? a.Self {
return a == bAsA
}

let x: RangeReplaceableCollection = /*...*/
let y: Collection = /*...*/

// If y has the same dynamic Element type as x, append it to x
var z: x.Self = x
if let yAsX = y as? Any {
z.append(yAsX)
}

`x.Self` then becomes just the first step in this direction.

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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[plx via swift-evolution]

> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Apr 13 2016, plx  > wrote:
> 
> Seriously, just because Swift has Optionals and they're useful for
> safety in some scenarios (compared with allowing everything to be
> nullable) does not mean that it's going to be “Swiftier” to apply a
> similar pattern everywhere.

This reminds me of something I was going to ask about earlier and forgot. 

Coming from other languages, I’ve definitely brought with me an assumption that 
“make invalid states unrepresentable (except where unavoidable)” is the right 
way to go, with deviations from that rule requiring scrutiny.

Is that outlook actually something the core team considers “Swift-y” or not, 
though? 

The connection to the point you’re making here and the question is that 
adopting this design style *will* lead to lots of optionals in lots of places.

> 
>> use an enum to reintroduce that value when necessary—than to `!`.
>> 
>> I don’t think the above is an *improvement* over the proposal, but it’s a 
>> route
>> that could have been taken.
> 
> I believe it would be hard to make such a design work at all, and if you
> could make it work I think you'd end up with exactly the problem this
> proposal aims to solve: references inside indices.  So, I don't think
> it's even a possibility, really.
> 
>> 
>> 
>>To help illustrate the claim, here’s a strawman “safe” API—for
>>illustration
>>only, not advocacy!—that would be safer and thus perhaps more 
>> “Swift-y”:
>> 
>>I think there's a prevalent misunderstanding (IOW, I don't mean to
>>single out this post or this poster) about what “safe” means in Swift
>>and what the features of a Swifty API are and should be. This
>>is a big topic worthy of much more time than I can devote here, but
>>here's a thought to start with:
>> 
>>A Swifty API helps you reason effectively about the correctness of your
>>code, and in part that means we provide enough preconditions on
>>arguments to avoid complicating result types, and code to handle
>>results, with optional-ness.
>> 
>>-- 
>>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 
>> 
> 
> -- 
> 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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[plx via swift-evolution]

> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Apr 13 2016, plx  wrote:
> 
>>On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution
>> wrote:
>> 
>>on Tue Apr 12 2016, plx
>> wrote:
>> 
>>Aside: `indices` being irregular can be a benefit in the context of
>>auto-complete.
>> 
>>* What is your evaluation of the proposal?
>> 
>>+1, very much.
>> 
>>As a change from the current model, it’s an across-the-board 
>> improvement
>>for me,
>>at least.
>> 
>>In a bigger-picture sense I think Swift would be better off by going
>>*further*
>>on certain aspects, but have said all that before.
>> 
>>* Is the problem being addressed significant enough to warrant a 
>> change
>>to
>>Swift?
>> 
>>It is, again very much so.
>> 
>>* Does this proposal fit well with the feel and direction of Swift?
>> 
>>Depends on the framing of the question.
>> 
>>Compared to the previous model, it’s an unqualified YES.
>> 
>>As a general proposition, I think this design is a local optimum for
>>overall
>>Swift-ness, but even so it’s creating a little un-Swifty pocket. It’s
>>“un-Swifty” in at least two ways:
>> 
>># 1: Relatively Unsafe, Pointer-Like Semantics
>> 
>>Indices—unsurprisingly!—behave quite a bit like pointers, and 
>> similarly
>>expose
>>*numerous* crashing combinations of `(value,operation)`:
>> 
>>- self[endIndex]
>>- self[startIndex] // <- when empty
>>- successor(of: endIndex)
>>- predecessor(of: startIndex)
>> 
>>…etc., which is *very much* reminiscent of the hazards of pointers.
>>(Technically
>>“undefined” not “crashing”, but being realistic “crashing" is usually
>>accurate).
>> 
>>No, these are unspecified in the general case, not undefined. Unless
>>you're working with, e.g. `UnsafeMutableBufferPointer` (or you have a
>>data race), there's no undefined behavior. The big problem with
>>pointers isn't what happens when they crash; it's what happens when they
>>*don't*.
>> 
>>Although Swift uses `Optional` to mitigate the hazards of `nil` 
>> pointers
>>(etc.),
>>you’re still left to your own devices for handling indices.
>> 
>>`Optional` is not “mitigating hazards;” it's encoding the possibility of
>>null in the type system. It's non-optional things that mitigate hazards.
>> 
>>This isn’t news to anyone here, I’m sure, and may even be unavoidable;
>>I’m just
>>pointing it out as an uncharacteristically-unsafe area in Swift’s
>>standard APIs,
>>and closer to how `!` and IOUs behave than otherwise typical.
>> 
>>Any time there's a required relationship between two things, e.g. a
>>receiver and an argument, you have a precondition. The existence of a
>>precondition does not make something unsafe at all in the sense that
>>Swift uses the term. Safety in swift is about type and memory safety in
>>the absence of data races, not about having APIs that respond sensibly
>>to every possible combination of arguments. Int.max + 1 will trap, but
>>that doesn't make addition unsafe.
>> 
>>Saying that it's close to how `!` behaves is not at all far from the
>>truth, because `!` has a precondition that its argument is non-nil.
>> 
>> I meant it as a much more exact analogy.
>> 
>> In a collections-move-indices world, you *could* handle indices as pointers 
>> have
>> been handled, bringing in support from the type-system:
>> 
>> enum SaferIndex {
>> case Position(T)
>> case End
>> }
>> 
>> …(yes, this is more-or-less `Optional` by another name).
>> 
>> The assumption above is `T` would be today’s “Index” types, w/o the value 
>> used
>> for `endIndex` (e.g. 0..> of
>> `DictionaryIndex` and `SetIndex`, and so on).
> 
> No, you can't, at least not usefully.  An Index that's at the end of one
> collection is in the middle of another, or with a suitably-modified version
> of the same collection.  

Sure, in certain concrete scenarios it’s possible for one collection’s indices 
to have such relationships to some other collection.

But, what of it? 

In a generic context you can’t assume this; in a concrete context you naturally 
have more information.

Slices would become problematic, I’ll grant.

>  var x = [1, 2]
>  let i = x.index(1, stepsFrom: x.startIndex)
>  x.removeLast()
>  x[i]   // fatal error: Index out of range

Indices can become invalid; this imposes preconditions. I don’t get it.

> 
> The converse is also true: subscripting on a collection's endIndex is
> sometimes just fine, even with no mutation in sight.
> 
>  let a = (0..<10).reversed()
>  

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dave Abrahams via swift-evolution]

on Wed Apr 13 2016, Dave Abrahams  wrote:

> on Mon Apr 11 2016, Nate Cook  wrote:
>
>> Proposal link:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md
>>
>> On Apr 11, 2016, at 2:59 PM, Dave Abrahams via swift-evolution
>>  wrote:
>>
>> Thanks for your comments, Brent!
>>
>> on Sun Apr 10 2016, Brent Royal-Gordon
>>  wrote:
>>
>> The shift described in this proposal is extremely valuable and makes
>> implementing collections far more intuitive, as all the collection's logic 
>> lives
>> "inside" the collection itself. My only hesitation is with the naming of the
>> method that Brent also called out:
>>
>> ... snip ...
>>
>> func index(n: IndexDistance, stepsFrom i: Index) -> Index
>>
>> Oof, I am really not a fan of this name. `steps` is sort-of a label 
>> on
>> the `n` parameter, but it's attached to `i`. 
>>
>> Oof indeed! This is a very unusual method in the standard library, since 
>> we're
>> calling on one instance to perform an action on another. My problems with the
>> naming are twofold: 
>>
>> (1) Collision with the index(of:) and index(where:) APIs
>> The existing methods are used for searching a collection, possibly finding a
>> matching index, possibly not. The new ones deterministically find an new 
>> index
>> at a prescribed distance, with important and slightly complicated 
>> preconditions.
>> These differences make the use and "flavor" of the two sets of methods 
>> distinct
>> enough that I think they should have different names.
>>
>> (2) Arguments are reversed
>> I think the ideal API for this would be index.advanced(by: 5, in: c), but I
>> prefer keeping the index-moving implementation in the collection, not the 
>> index.
>> I would favor any naming for this method that puts the index before the
>> distance, keeping the overall shape of the advanced(by:) method. c.advance(i,
>> by: 4) would be my pick.
>
> Dmitri, Max, and I just talked this over and we think you're right on
> both counts.  Having these “index” overloads appear in completion lists
> alongside the ones that are there for use as high-level algorithms seems
> wrong.  Also, since the method either returns a modified version of the
> index or modifies the index in place, the index argument is “more
> primary” and should come first.  Here's what we came up with:
>
>  let j = location(i, offsetBy: 5)
>
>  formLocation(, offsetBy: -2)
>
> Feedback welcome.

Updated proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md

-- 
Dave

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

Re: [swift-evolution] [Proposal] mapValues

[Andrew Bennett via swift-evolution]

I don't think I've ever called map on a dictionary in production code, only
a mapValue function like this thread discusses. When do we actually want to
call map on a dictionary? I feel like mapValue should be the default.

I'm wondering if `Dictionary.Element`should be `Value`, instead
of `(Key,Value)`.


With an array you can do this:

for (key, value) in ["a", "b", "c"].enumerate() {

print(key, value) // 0 a, 1 b, 2 c

}


Shouldn't the equivalent for a dictionary be this?


for (key, value) in ["a": 0, "b": 1, "c": 2].enumerate() {

print(key, value) // a 0, b 1, c 2

}


Not this:


for (key, value) in ["a": 0, "b": 1, "c": 2] {

print(key, value) // a 0, b 1, c 2

}


Presumably the old syntax would produce only values:


for value in ["a": 0, "b": 1, "c": 2] {

print(value) // 0, 1, 2

}


You can still iterate the keys like this:


for key in ["a": 0, "b": 1, "c": 2].keys {

print(key) // a, b, c

}

I think I understand the reasoning for Dictionary the way it is, but I
think it only provides consistency to the implementation, not the interface.

The result of all this being that Dictionary is more consistent (IMO), and
map would work on the values of all collection types, not a mix of values
and key/value pairs.

What do you think?



On Thu, Apr 14, 2016 at 9:07 AM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Wed Apr 13 2016, Nate Cook  wrote:
>
> > On Apr 13, 2016, at 12:02 PM, Jacob Bandes-Storch via swift-evolution
> >  wrote:
> >
> > To adhere to the API Design Guidelines, I think it should be named
> > "mappingValues", right?
> >
> > On Wed, Apr 13, 2016 at 4:23 AM, Vladimir.S via swift-evolution
> >  wrote:
> >
> > As for mapKeys and many values into a single key. I believe we
> should have a
> > choice - do we expect multiply values for the same key or not.
> Just like
> > "+" and integer overflow : by default it raises the error, but
> if "&+" -
> > we expect the overflow. I can imagine situations when it is ok
> for me to
> > have different values for the same key(if I don't care which of
> values
> > should be for that key in result dictionary).
> > So my proposal is some additional mapKey(allowMultiplyValues:
> true)
> > {...} or in any other form/name.
> >
> > There's a proposal (awaiting merging) to add Dictionary initializers and
> methods
> > that work with key/value pairs. These provide different ways of dealing
> with the
> > duplicate key issue after a call to the regular Collection.map method.
> >
> >
> https://github.com/natecook1000/swift-evolution/blob/natecook-dictionary-merge/proposals/-add-sequence-based-init-and-merge-to-dictionary.md
>
> Ah, yes, that reminds me of your answer to the question about whether we
> need a “uniquingKeys” label on that init(), which IMO is a good one: no,
> we don't need it, because the one without the label traps on duplicate
> keys.
>
> > I'd be interested in a `mapValues` or `transformValues` method that
> would modify
> > values in place while leaving keys alone.
>
> Is that enough of an improvement over
>
>Dictionary(d.lazy.map { (k,v) in (k, transform(v)) })
>
> (once we get that initializer) to make it worth expanding the Dictionary
> API?
>
> > Another useful method (that could be used to build mapValues more
> efficiently)
> > would be `Dictionary.updateValue(value: Value, at index:
> DictionaryIndex)`, so
> > you could write:
> >
> > var dict = ["a": 1, "b": 2, "c": 3]
> > if let i = dict.index(where: { $0.value == 3 }) {
> > dict.updateValue(100, at: i)
> > }
> > // dict == ["a": 1, "b": 2, "c": 100]
>
> Indeed it would!
>
> > -Nate
> >
> > On 13.04.2016 13:38, Ross O'Brien via swift-evolution wrote:
> >
> > +1 on mapValues.
> >
> > DictionaryLiteral already throws an exception if it includes
> > duplicate
> > keys, so I'd expect mapKeys to throw an error if multiple
> source
> > keys
> > mapped to the same destination key.
> >
> > On Wed, Apr 13, 2016 at 11:28 AM, Miguel Angel Quinones via
> > swift-evolution
> >  > >
> > wrote:
> >
> > I'm +1 for adding mapValues. Very useful functionality and
> trivial
> > to
> > implement.
> >
> > > > I.e. I suggest to implement and mapKeys() also. It could
> be also
> > useful in some situations.
> > > `mapKeys` is much more dangerous, because you could end up
> mapping
> > many values into a single key. You kind of need to combine
> the
> > values somehow. Perhaps:
> > >
> > > extension Dictionary {
> > > func mapValues__(_ 

Re: [swift-evolution] [SR-933] Rename flatten to flattened

[Howard Lovatt via swift-evolution]

With regard to trig they are functions:

 let s = sin(x)

so not really relevant. But if the were made members then:

  let s = x.sined
  x.sin()

Would read well.

On Tuesday, 12 April 2016, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> >> Do you also think that trigonometry should be `foo.sined`,
> `foo.cosined`, and `foo.tangented`?
> >
> > sine, cosine etc. are all nouns so I think as computed properties they’d
> be fine as is?
>
> So you would favor these?
>
> _ = number.sine()
> _ = number.cosine()
> _ = number.tangent()
>
> number.formSine()
> number.formCosine()
> number.formTangent()
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dave Abrahams via swift-evolution]

on Wed Apr 13 2016, plx  wrote:

>> On Apr 13, 2016, at 4:26 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Tue Apr 12 2016, Brent Royal-Gordon  wrote:
>> 
>
>>> In these cases, it would be better if the `successor(of:)` method was
>>> designed in a way that acknowledged and encapsulated the bounds check
>>> that is usually required when it is used:
>>> 
>>> while let nextIndex = collection.successor(of: index) {
>>> …
>>> index = nextIndex
>>> }
>> 
>> I disagree; it doesn't make sense that I should have to check for nil
>> when I'm not really interested in the end of the collection as in my
>> example above.  Many other nontrivial algorithms will have the same
>> characteristic.  If all you need is to loop through indices to the end,
>> there are lots of ways to do it.  
>> 
>> Looking closer, what you've got here is actually a *highly* unusual
>> case, where you want a pair of indices that you want to always point to
>> successive elements.  I do not know of any algorithm that would use this
>> except maybe bubblesort, and frankly I cannot see any reason to change
>> the standard library to support it.  Am I missing something?
>
> Enumerating adjacent pairs from a sequence has its uses; when it’s a
> collection you can make the "adjacent pairs” thing itself a
> collection, and a pair of adjacent indices from the source collection
> makes a natural choice for the non-end-index indices.
>
> In this case I agree the language doesn’t need to change; just write
> the generic “adjacent pairs” thingy and then use it like so:
>
>   // if you *really* wanted values:
>   for (left,right) in collection.adjacentPairs() { …
>
>   // if you *did* actually want indices;
>   for (leftIndex,rightIndex) in collection.indices.adjacentPairs() {
>
> …but all the uses I make of it for higher-level things than
> e.g. “algorithms” in the STL sense.

At that level, I think you shouldn't be using low-level index
manipulation anyway, which is to say I agree that your adjacentPairs
adapter is the right way to go.

-- 
Dave

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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[plx via swift-evolution]

> On Apr 13, 2016, at 4:26 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Apr 12 2016, Brent Royal-Gordon  wrote:
> 
>> In these cases, it would be better if the `successor(of:)` method was
>> designed in a way that acknowledged and encapsulated the bounds check
>> that is usually required when it is used:
>> 
>>  while let nextIndex = collection.successor(of: index) {
>>  …
>>  index = nextIndex
>>  }
> 
> I disagree; it doesn't make sense that I should have to check for nil
> when I'm not really interested in the end of the collection as in my
> example above.  Many other nontrivial algorithms will have the same
> characteristic.  If all you need is to loop through indices to the end,
> there are lots of ways to do it.  
> 
> Looking closer, what you've got here is actually a *highly* unusual
> case, where you want a pair of indices that you want to always point to
> successive elements.  I do not know of any algorithm that would use this
> except maybe bubblesort, and frankly I cannot see any reason to change
> the standard library to support it.  Am I missing something?

Enumerating adjacent pairs from a sequence has its uses; when it’s a collection 
you can make the "adjacent pairs” thing itself a collection, and a pair of 
adjacent indices from the source collection makes a natural choice for the 
non-end-index indices.

In this case I agree the language doesn’t need to change; just write the 
generic “adjacent pairs” thingy and then use it like so:

  // if you *really* wanted values:
  for (left,right) in collection.adjacentPairs() { …

  // if you *did* actually want indices;
  for (leftIndex,rightIndex) in collection.indices.adjacentPairs() {

…but all the uses I make of it for higher-level things than e.g. “algorithms” 
in the STL sense.

> 
>> Given the difficulties of statically detecting index invalidation, I
>> totally agree that (as you discussed in a section I've snipped) we
>> can't statically prove indexes are safe. But we can, at the point
>> where we generate an index, easily check if that index is *currently*
>> valid. And it's something that most callers will have to do anyway if
>> we don't do it ourselves.
> 
> I really disagree with the assertion that most callers will need to do
> this.  It certainly isn't a normal thing to do in any algorithm I know
> of.  If you think I'm wrong (not unheard of!), I suggest you code up the
> method you've requested and try to apply it in actual code that
> manipulates indices, and show us how it improved the code.
> 
>>> We will change the index(_:stepsFrom:limitedBy:) overload to return
>>> an optional, and we will see what other implications it has, and how
>>> it fits into the rest of the system.
>> 
>> I'm glad to hear you'll evaluate this option, and I think it can give
>> us both what we want from this API.
>> 
>> I think having the most high-level operations incorporate bounds
>> checks, while the lower-level ones don't, is a good compromise. 
> 
> That may be the pattern you discern in Swift's bounds checks, but I just
> want to be very clear that it's not a criterion we use to make the
> determination.  I would love it if we had a more systematic way to make
> the choice to insert bounds checks or not, but for now it remains
> something of an art, trying to balance usability and performance
> concerns.
> 
>> If we encourage people to use `index(_:stepsFrom:limitedBy:)` unless
>> they know what they're doing, naïve clients will get an implicit
>> bounds check, while sophisticated, speed-sensitive clients can use
>> methods like `successor(of:)` which require them to check bounds
>> manually.
> 
> It's not a bounds check.  There are lots of ways to pass a limit that's
> outside the bounds of the collection, and you can pass a limit that's in
> the opposite direction from the offset.  If they happen to pass the
> collection's endIndex and a positive offset, it degenerates to a bounds
> check, but that's not what this method is for.
> 
> I will encourage people to use high-level algorithms where possible, so
> they're not doing index manipulations directly.  Anyone doing low-level
> index manipulations is probably implementing an algorithm, and I'll
> encourage them to do whatever will be most efficient, and then test the
> algorithm on some very strict models of Collection, that check
> everything.  You can find some of these in the StdlibUnittest library in
> the swift source tree.
> 
>> (There might even be a case for offering bounds-checked
>> `successor(of:limitedBy:)` and `predecessor(of:limitedBy:)` methods to
>> give people bounds-checked alternatives to all three.)
>> 
>>> Thanks again, Brent.
>> 
>> Thank you!
> 
> -- 
> Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dave Abrahams via swift-evolution]

on Mon Apr 11 2016, Nate Cook  wrote:

> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md
>
> On Apr 11, 2016, at 2:59 PM, Dave Abrahams via swift-evolution
>  wrote:
>
> Thanks for your comments, Brent!
>
> on Sun Apr 10 2016, Brent Royal-Gordon
>  wrote:
>
> The shift described in this proposal is extremely valuable and makes
> implementing collections far more intuitive, as all the collection's logic 
> lives
> "inside" the collection itself. My only hesitation is with the naming of the
> method that Brent also called out:
>
> ... snip ...
>
> func index(n: IndexDistance, stepsFrom i: Index) -> Index
>
> Oof, I am really not a fan of this name. `steps` is sort-of a label on
> the `n` parameter, but it's attached to `i`. 
>
> Oof indeed! This is a very unusual method in the standard library, since we're
> calling on one instance to perform an action on another. My problems with the
> naming are twofold: 
>
> (1) Collision with the index(of:) and index(where:) APIs
> The existing methods are used for searching a collection, possibly finding a
> matching index, possibly not. The new ones deterministically find an new index
> at a prescribed distance, with important and slightly complicated 
> preconditions.
> These differences make the use and "flavor" of the two sets of methods 
> distinct
> enough that I think they should have different names.
>
> (2) Arguments are reversed
> I think the ideal API for this would be index.advanced(by: 5, in: c), but I
> prefer keeping the index-moving implementation in the collection, not the 
> index.
> I would favor any naming for this method that puts the index before the
> distance, keeping the overall shape of the advanced(by:) method. c.advance(i,
> by: 4) would be my pick.

Dmitri, Max, and I just talked this over and we think you're right on
both counts.  Having these “index” overloads appear in completion lists
alongside the ones that are there for use as high-level algorithms seems
wrong.  Also, since the method either returns a modified version of the
index or modifies the index in place, the index argument is “more
primary” and should come first.  Here's what we came up with:

 let j = location(i, offsetBy: 5)

 formLocation(, offsetBy: -2)

Feedback welcome.

-- 
Dave

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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dave Abrahams via swift-evolution]

on Wed Apr 13 2016, plx  wrote:

> On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution
>  wrote:
>
> on Tue Apr 12 2016, plx
>  wrote:
>
> Aside: `indices` being irregular can be a benefit in the context of
> auto-complete.
>
> * What is your evaluation of the proposal?
>
> +1, very much.
>
> As a change from the current model, it’s an across-the-board 
> improvement
> for me,
> at least.
>
> In a bigger-picture sense I think Swift would be better off by going
> *further*
> on certain aspects, but have said all that before.
>
> * Is the problem being addressed significant enough to warrant a 
> change
> to
> Swift?
>
> It is, again very much so.
>
> * Does this proposal fit well with the feel and direction of Swift?
>
> Depends on the framing of the question.
>
> Compared to the previous model, it’s an unqualified YES.
>
> As a general proposition, I think this design is a local optimum for
> overall
> Swift-ness, but even so it’s creating a little un-Swifty pocket. It’s
> “un-Swifty” in at least two ways:
>
> # 1: Relatively Unsafe, Pointer-Like Semantics
>
> Indices—unsurprisingly!—behave quite a bit like pointers, and 
> similarly
> expose
> *numerous* crashing combinations of `(value,operation)`:
>
> - self[endIndex]
> - self[startIndex] // <- when empty
> - successor(of: endIndex)
> - predecessor(of: startIndex)
>
> …etc., which is *very much* reminiscent of the hazards of pointers.
> (Technically
> “undefined” not “crashing”, but being realistic “crashing" is usually
> accurate).
>
> No, these are unspecified in the general case, not undefined. Unless
> you're working with, e.g. `UnsafeMutableBufferPointer` (or you have a
> data race), there's no undefined behavior. The big problem with
> pointers isn't what happens when they crash; it's what happens when they
> *don't*.
>
> Although Swift uses `Optional` to mitigate the hazards of `nil` 
> pointers
> (etc.),
> you’re still left to your own devices for handling indices.
>
> `Optional` is not “mitigating hazards;” it's encoding the possibility of
> null in the type system. It's non-optional things that mitigate hazards.
>
> This isn’t news to anyone here, I’m sure, and may even be unavoidable;
> I’m just
> pointing it out as an uncharacteristically-unsafe area in Swift’s
> standard APIs,
> and closer to how `!` and IOUs behave than otherwise typical.
>
> Any time there's a required relationship between two things, e.g. a
> receiver and an argument, you have a precondition. The existence of a
> precondition does not make something unsafe at all in the sense that
> Swift uses the term. Safety in swift is about type and memory safety in
> the absence of data races, not about having APIs that respond sensibly
> to every possible combination of arguments. Int.max + 1 will trap, but
> that doesn't make addition unsafe.
>
> Saying that it's close to how `!` behaves is not at all far from the
> truth, because `!` has a precondition that its argument is non-nil.
>
> I meant it as a much more exact analogy.
>
> In a collections-move-indices world, you *could* handle indices as pointers 
> have
> been handled, bringing in support from the type-system:
>
> enum SaferIndex {
> case Position(T)
> case End
> }
>
> …(yes, this is more-or-less `Optional` by another name).
>
> The assumption above is `T` would be today’s “Index” types, w/o the value used
> for `endIndex` (e.g. 0.. `DictionaryIndex` and `SetIndex`, and so on).

No, you can't, at least not usefully.  An Index that's at the end of one
collection is in the middle of another, or with a suitably-modified version
of the same collection.  

  var x = [1, 2]
  let i = x.index(1, stepsFrom: x.startIndex)
  x.removeLast()
  x[i]   // fatal error: Index out of range

The converse is also true: subscripting on a collection's endIndex is
sometimes just fine, even with no mutation in sight.

  let a = (0..<10).reversed()
  print(Array(a))  // “[9, 8, 7, 6, 5, 4, 3, 2, 1, 0]”

  let b = a.prefix(9)
  print(Array(b))  // “[9, 8, 7, 6, 5, 4, 3, 2, 1]”

  print(a[b.endIndex]) // “0” (correct, supported behavior)

Of course,

  b[b.endIndex]// As a matter of QOI: fatal error: out of bounds: index 
>= endIndex

>
> It would’ve been awkward to do this under the previous status quo—e.g. even 
> for
> arrays your indices would have to have a back-reference to get the count, and
> thus couldn’t be plain integers—but the collection will now always be present 
> to
> provide such info.
>
> Cons:
>
> - more 

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Tony Parker via swift-evolution]

> On Apr 13, 2016, at 12:57 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Apr 13 2016, Dave Abrahams  wrote:
> 
>>> Reverse is the best opposite we have of advance, so it makes sense to
>>> me. 
>> 
>> Oh, I get it.
>> 
>>> Or we could use retreat. =) There are other pairs of words that work
>>> as well, like “increment/decrement”. 
>> 
>> Yeah, unfortunately those carry an incorrect implication when the
>> indices are numbers, because, e.g. the collection might be offsetting
>> the number by 2 for each position.  One could of course argue that using
>> numbers that way as indices was a bad design choice.
>> 
>> I'll have to think about that idea again.  We considered and rejected it
>> for a reason, but it might not be a really strong one.  Thanks for
>> bringing it up.
> 
> ...and having talked it over at lunch, now I remember why we rejected
> it: there's no good way to make a nonmutating version.
> 
>  let x = c.incremented(i)   // reads like an assertion about the past
>  let y = c.incrementing(i)  // reads like it has side-effects and returns c, 
> or
> // a new version of c
> 

In fact, it does return a new version* of c; just like this:

let s2 = myString.appending(“foo”)

*new version: the result is related to the argument

This works out great:

let next = c.incrementing(first)
c.increment()

- Tony

> APIs where the receiver returns a modified version of an argument don't
> lend themselves to verb forms.
> 
> -- 
> 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

Re: [swift-evolution] [Proposal] Safer half-open range operator

[Dave Abrahams via swift-evolution]

on Wed Apr 13 2016, Maximilian Hünenberger  wrote:

> Should this new operator form a new range? How can this range know about the
> array's indices?
>
> A while ago there was a proposal (unfortunately it was not discussed enough)
> which introduced safe array indexing:
>
> array[safe: 3] // returns nil if index out of bounds

Wrong label, but I wouldn't be opposed to adding such an operator for
all Collections.

> So another way to handle this issue would be to make another subscript like:
>
> array[truncate: -1...6]

That approach makes sense too.  But then do we add

  x[python: 0..<-2] // all but the last two elements?

;^)

> Best regards
> - Maximilian
>
> Am 12.04.2016 um 01:21 schrieb Luis Henrique B. Sousa via swift-evolution
> :
>
> The idea of having a new operator following the principles of overflow
> operators looks great. Two distinct operators doing implicit and 
> explicitly
> might really be a good way to go; it would be concise and wouldn't look 
> like
> some magic happened behind the scenes. I'd like to hear more opinions 
> about
> it.
>
> > what we'll have in case a[-1 &..< 5]? should this raise error or become 
> [0
> ..< 3] ? I think, the latter.
> I agree here, I'd choose the latter.
>
> From my perspective, the behaviour I'm proposing is what a considerable
> number of users expect, especially if coming from other languages that
> follow that path. Of course I'm not comparing languages here, but
> considering the Swift principles of being a safer language, in my opinion
> we'd rather have a partial slice than a crash in execution time (when the
> user is not totally aware of it).
>
> Many thanks for all your additions so far. It's really good to see that
> these things are not set in stone yet.
>
> - Luis
>
> On Apr 11, 2016 4:21 PM, "Vladimir.S via swift-evolution"
>  wrote:
>
> +1 for the idea "in general". But I also think that explicit is better 
> than
> implicit, especially if we deal with possible errors. Just like we 
> work
> in Swift with integer overflow : '+' will generate run time error, but
> saying &+ we point Swift that we know what we do.
>
> but.. what we'll have in case a[-1 &..< 5]? should this raise error or
> become [0 ..< 3] ? I think, the latter.
>
> On 11.04.2016 17:02, Haravikk via swift-evolution wrote:
>
> I like the idea in theory, but the question is; is it really safer to
> return a result that the developer may not have wanted, versus an
> error
> indicating that a mistake may have been made? I wonder if perhaps
> there
> could be an alternative, such as a variation of the operator like
> so:
>
> let b = a [0 &..< 5]// Equivalent to let b = a[0 ..< min(5,
> a.endIndex)],
> becomes let b = a[0 ..< 3]
>
> I’m just not sure that we can assume that an array index out of
> range error
> is okay without some kind of indication from the developer, as
> otherwise we
> could end up returning a partial slice, which could end up causing
> an error
> elsewhere where the size of the slice is assumed to be 5 but 
> isn’t.
>
> On 11 Apr 2016, at 13:23, Luis Henrique B. Sousa via
> swift-evolution
>  >
> wrote:
>
> This proposal seeks to provide a safer ..< (aka half-open 
> range
> operator)
> in order to avoid **Array index out of range** errors in
> execution time.
>
> Here is my first draft for this proposal:
> 
> https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/-safer-half-open-range-operator.md
>
> In short, doing that in Swift causes a runtime error:
>
> leta =[1,2,3]
> letb =a[0..<5]
> print(b)
>
> > Error running code:
> > fatal error: Array index out of range
>
> The proposed solution is to slice the array returning all
> elements that
> are below the half-open operator, even though the number of
> elements is
> lesser than the ending of the half-open operator. So the 
> example
> above
> would return [1,2,3].
> We can see this very behaviour in other languages, such as
> Python and
> Ruby as shown in the proposal draft.
>
> This would eliminate the need for verifications on the array
> 

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dave Abrahams via swift-evolution]

on Tue Apr 12 2016, Brent Royal-Gordon  wrote:

> Yes, I totally agree that `Collection.subscript(_: Index)` should not
> be Optional.
>
> But I think that index-manipulation methods like `successor(of:)` are
> a different story. It is normal and expected that, when you alter an
> index, you will occasionally hit the boundaries of the
> collection. There certainly are cases where you know a particular
> index manipulation is safe, but most index manipulations need to be
> guarded by something like:
>
>   while index < collection.endIndex {
>   let nextIndex = collection.successor(of: index)
>   …
>   index = nextIndex
>   }

I disagree that this should be considered a “guard.”  You are testing
against another index—a basic feature of what makes something an index.
It's probably a bit more likely that this other index is at the end of
the collection, but it might not be.  For example, look at the algorithm
for reversing a collection in place:

  extension BidirectionalCollection where Self : MutableCollection {
mutating func reverse() {
  if isEmpty { return } // early exit eliminates a branch in the loop
  var i = startIndex
  var j = predecessor(of: endIndex)
  while i < j {
swap([i], [j])
formSuccessor()
formPredecessor()
  }
}
  }

[Why isn't this in the stdlib?! Someone file a bug and write a proposal,
quick!]

> In these cases, it would be better if the `successor(of:)` method was
> designed in a way that acknowledged and encapsulated the bounds check
> that is usually required when it is used:
>
>   while let nextIndex = collection.successor(of: index) {
>   …
>   index = nextIndex
>   }

I disagree; it doesn't make sense that I should have to check for nil
when I'm not really interested in the end of the collection as in my
example above.  Many other nontrivial algorithms will have the same
characteristic.  If all you need is to loop through indices to the end,
there are lots of ways to do it.  

Looking closer, what you've got here is actually a *highly* unusual
case, where you want a pair of indices that you want to always point to
successive elements.  I do not know of any algorithm that would use this
except maybe bubblesort, and frankly I cannot see any reason to change
the standard library to support it.  Am I missing something?

> Given the difficulties of statically detecting index invalidation, I
> totally agree that (as you discussed in a section I've snipped) we
> can't statically prove indexes are safe. But we can, at the point
> where we generate an index, easily check if that index is *currently*
> valid. And it's something that most callers will have to do anyway if
> we don't do it ourselves.

I really disagree with the assertion that most callers will need to do
this.  It certainly isn't a normal thing to do in any algorithm I know
of.  If you think I'm wrong (not unheard of!), I suggest you code up the
method you've requested and try to apply it in actual code that
manipulates indices, and show us how it improved the code.

>> We will change the index(_:stepsFrom:limitedBy:) overload to return
>> an optional, and we will see what other implications it has, and how
>> it fits into the rest of the system.
>
> I'm glad to hear you'll evaluate this option, and I think it can give
> us both what we want from this API.
>
> I think having the most high-level operations incorporate bounds
> checks, while the lower-level ones don't, is a good compromise. 

That may be the pattern you discern in Swift's bounds checks, but I just
want to be very clear that it's not a criterion we use to make the
determination.  I would love it if we had a more systematic way to make
the choice to insert bounds checks or not, but for now it remains
something of an art, trying to balance usability and performance
concerns.

> If we encourage people to use `index(_:stepsFrom:limitedBy:)` unless
> they know what they're doing, naïve clients will get an implicit
> bounds check, while sophisticated, speed-sensitive clients can use
> methods like `successor(of:)` which require them to check bounds
> manually.

It's not a bounds check.  There are lots of ways to pass a limit that's
outside the bounds of the collection, and you can pass a limit that's in
the opposite direction from the offset.  If they happen to pass the
collection's endIndex and a positive offset, it degenerates to a bounds
check, but that's not what this method is for.

I will encourage people to use high-level algorithms where possible, so
they're not doing index manipulations directly.  Anyone doing low-level
index manipulations is probably implementing an algorithm, and I'll
encourage them to do whatever will be most efficient, and then test the
algorithm on some very strict models of Collection, that check
everything.  You can find some of these in the StdlibUnittest library in
the swift 

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dave Abrahams via swift-evolution]

on Tue Apr 12 2016, Patrick Smith  wrote:

> +1 to Tony’s naming suggestions, myself preferring move(index:by:), move
> (indexForward:), and move(indexBackward:) as it is the most clear and
> consistent.

Sure, any individual operation in a mutating/nonmutating pair can be
better named if you don't consider how to name the corresponding
operation such that the names preserve the relationship.  How do you
name the nonmutating versions of these?

> As an aside, I am not a fan of the form- prefix, as it feels generic
> without being self explanatory. I think another word would work
> better. 

Yeah, practically everybody including me has the same feeling: there's
probably a better answer out there.  Problem is, what is it?  [There's a
better pair of words, except that we can't use those].

> I won’t bikeshed, 

Please, be my guest and bikeshed.  It's more useful to come up with
alternatives than to simply state dissatisfaction with the status quo.

> but I feel form- feels and reads oddly every time I see it.
>
> > On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution
>  wrote:
> > 
> > Hello Swift community,
> > 
> > The review of "A New Model for Collections and Indices" begins now and
> runs through April 18th. The proposal is available here:
> > 
> >
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.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.
> > 
> > 
> > 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?
>
> I agree with the general direction and scope of the proposal, but I think
> the names could use some changes. Specifically, I don’t think the fallback
> to ‘form’ is required. It would be a significant readability improvement 
> to
> use a meaningful verb to describe the action of altering the argument. The
> methods that create new indices probably need a label on the first 
> argument,
> because otherwise it looks as if the IndexDistance is what is described by
> ‘index’.
>
> Proposed:
>
> func successor(of i: Index) -> Index
>
> func formSuccessor(i: inout Index)
>
> Instead, I suggest:
>
> func successor(of i : Index) -> Index
>
> func advance(i: inout Index)
>
> Proposed:
>
> func index(n: IndexDistance, stepsFrom i: Index) -> Index
>
> func index(n: IndexDistance, stepsFrom i: Index, limitedBy limit: Index) 
> ->
> Index
>
> func formIndex(n: IndexDistance, stepsFrom i: inout Index)
>
> func formIndex(n: IndexDistance, stepsFrom i: inout Index, limitedBy 
> limit:
> Index)
>
> Suggested (taking into account Nate’s suggestion of reversing the order):
>
> func index(startingAt i: Index, movedBy n: IndexDistance) -> Index
>
> func index(startingAt i: Index, movedBy n: IndexDistance, limitedBy limit:
> Index) -> Index
>
> func move(i : inout Index, by n: IndexDistance)
>
> func move(i : inout Index, by n: IndexDistance, limitedBy limit: Index)
>
> Proposed:
>
> func predecessor(of i: Index) -> Index
>
> func formPredecessor(i: inout Index)
>
> Suggested:
>
> func predecessor(of i: Index) -> Index
>
> func reverse(i: inout Index)
>
> I think reversing an index has some nice symmetry with reversing a 
> sequence,
> but if it seems to confusing, then replace advance and reverse with
> ‘moveForward’ and ‘moveBackward’.
>
> - Tony
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

Re: [swift-evolution] [Proposal] Safer half-open range operator

[Luis Henrique B. Sousa via swift-evolution]

Another common application would be on pagination systems. For example,
this function that I just found randomly:
https://github.com/MrAlek/PagedArray/blob/bf64cbb140cf8bd109483dd749ac40a5f4531dfd/Source/PagedArray.swift#L88


public func indexes(pageIndex: Int) -> Range {
assert(pageIndex >= startPageIndex && pageIndex <= lastPageIndex, "Page
index out of bounds")

let startIndex: Index = (pageIndex-startPageIndex)*pageSize
let endIndex: Index
if pageIndex == lastPageIndex {
endIndex = count
} else {
endIndex = startIndex+pageSize
}

return (startIndex.. let current = pageIndex * pageSize
> array[safe: (current - pageSize) ..< (current + pageSize)]

(or *truncate* according to the user expectation) instead, which in my
opinion looks much more elegant and handy.


Regards,

- Luis

On Wed, Apr 13, 2016 at 7:37 PM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 13.04.2016 19:59, Pyry Jahkola wrote:
>
>> On 13 Apr 2016, at 17:53, Luis Henrique B. Sousa >> > wrote:
>>>
>>> (…) I totally agree with @Vladimir that we could have a more clear and
>>> /swift-ly/ way to concisely wrap those operations.
>>>
>>> The behaviour pointed out by him looks very nice and doable to me.
>>>
>>> a = [1,2,3]
>>> a[-1..<6] - raises runtime error (right behavior by default, doesn't
>>> affect existing code)
>>> a[truncate: -1..<6] - produces [1,2,3] (the very behaviour I proposed
>>> initially)
>>> a[safe: -1..<6] - produces nil (i.e [T]?) (no runtime errors and makes it
>>> easy to handle unexpected results)
>>>
>>
>> I don't feel strongly about this. Yes, if this were shorter to express, it
>> would feel like /nicer/ design. But what Haravikk and Chris L. already
>> said
>> seems to me as /wiser/ design.
>>
>
>
> IMO it is not just nicer, it provides you with handy and explicit
> alternatives.
>
> In some situations, you are checking bounds and you sure that if you
> calculated them incorrectly - error will be raised.
> But sometimes, you don't need to check exact bounds, probably "take these
> values, or give me nil of no such".
>
> I can compare this with Dictionary we have in Swift.
> Can you say if it is "wise" to return Optional(T) when we calls
> dict[somekey] ? Probably it is wise to raise error if there is no such key?
> (to force us to check the key first).
>
> The proposed subscript for special situations when you know you need
> exactly this behavior to make your code clear and readable and you fully
> controls code flow.
>
>
>> (@Vladimir: Besides, I'm sure `.clamped(to:)` wasn't invented for this
>> purpose but for doing interval arithmetic on ranges. It just happens to
>> somewhat work here.)
>>
>> – Would this feature really provide a measurable benefit to developers?
>> – Under which circumstances do you find yourself with a past-the-end upper
>> bound such as 6 where `a.count == 3`?
>> – …Let alone a /negative/ start index like `-1`?
>>
>> I find cases like these to be much more common in languages like Python
>> and
>> Ruby where e.g. `array[-2]` refers to the penultimate element. Swift
>> doesn't seem to want to go there.
>>
>>
> Each good feature will provide benefit to developers. For those, who work
> a lot with arrays/bounds/slices/copies this will provide measurable
> benefit, IMO.
> Can we live without such improvement? Absolutely. Are there more important
> proposals? Yes. But will this make Swift more elegant, handy, clear? Yes, I
> believe.
>
> As for "Under which circumstances.." questions. Well.. something like "get
> +- 5 elements(at max) with center in some index"
>
> let a = [1,2,3,4,5,6]
> let index = random(0.. let result = a[truncate: index-5...index+5]
>
> or "get 5 elements from index, if no 5 elements from index - return empty
> array"
>
> let a = [1,2,3,4,5,6]
> let index = random(0.. if let result = a[safe: index..  {return result}
> else
>  {return []}
>
> Something like this.
>
>
> For the use cases I can think of, Swift 3—as the proposal currently goes
>> <
>> https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/Collection.swift#L724-L808
>> >—already
>> offers the following suitable methods:
>>
>>  array[bounds]
>>  array.prefix(maxLength)// no precondition
>>  array.prefix(upTo: index)
>>  array.prefix(through: index)
>>  array.dropLast(n)// no precondition
>>  array.dropFirst(n)// no precondition
>>  array.suffix(from: index)
>>  array.suffix(maxLength)  // no precondition
>>
>> If these feel too clumsy to use, maybe we should focus on making them all
>> more convenient. Ideally, that suggestion would apply to all
>> `Collection`s.
>>
>> — Pyry
>>
>>
> Yes, some variants can be covered by these methods:
> array.prefix(maxLength) -> array[truncate: 

Re: [swift-evolution] What about a VBA style with Statement?

[Michael Peternell via swift-evolution]

I think the idea is good, but I think it would be bad for the language overall.

-1

As a plus, it makes code easier to write, sometimes; or at least it seems so. 
On the other hand, I think it makes code harder to comprehend. A `with` 
statement introduces a new scope in which it is not obvious what exactly 
happens. For example:

with(someObject) {
foo()
}

what does it do? The mere fact that I wrote `with(someObject)` suggests that 
`someObject.foo()` is what should happen. But it could also mean `self.foo()` 
or just the global function `foo()`.

Usually, you can see from the lexical surrounding of a call, what is happening. 
`foo()` means either `self.foo()`, or it means `foo()`. It's okay that I, as 
the class author know if my class has a `foo()` method or not. But do I have to 
know the API of someObject completely, including any future changes to its API?

For example: Suppose I have a class Foo, which has a method foo(). A remote 
co-worker wrote class Bar, which has a method bar(). Because I need bar a lot 
recently, I decided to use the with() form:

with(someBarObject) {
   ...
   foo()
   ...
   bar()
   ...
   bar()
   ...
   foo()
}

All is fine, it's clear that foo() calls my method and bar() calls that method 
on the someBarObject object. Then, suddenly, my co-worker had a great idea! He 
also implements foo() - it cannot break any existing code doing so, because 
existing code will not call foo(), because up until now class Bar did not 
implement foo(), after all...

Suddenly, my Foo class breaks, because my co-worker implemented foo() in his 
own class :-o

Such a thing really shouldn't happen. I am arguing that `with` is an inherently 
unsafe language feature! I also think it doesn't make the code actually easier 
to read. It may be an advantage if you have some 
reallyReallyLongAndFunnyVariableNames_withUnderscores_andSpecialTypeAnnotations,
 but even then I think it isn't worth it. I prefer easy-to-read over 
easy-to-write.

I like it when I can know what some code does, just by looking at it locally. 
These are syntactic guarantees that I can depend on. E.g. when I read something 
like

x.bar()
foo()

I know that there is an x variable somewhere (either in the current instance, 
or globally, or a local variable; a global variable is unlikely, because no one 
should dare to call a local variable just x.)
I know that the bar() method is called on that variable x, so x implements the 
bar() method. Either itself, or through an extension.
foo() is either a global method, or an instance method, or a static method.
All of these questions can be answered if I just know the class that I am 
currently implementing. If I know that my class didn't implement foo(), then 
foo() must be global. If x is a local var, an iVar or a static var, I can tell 
just by looking at the surrounding code. If it isn't => it must be global.
This (let me call it) "lexical decidability" is reduced by a `with`-operator, 
and this is the primary reason why I don't like it. For exactly this reason, I 
use a convention when writing Objective C code, that iVars should always be 
prefixed by an underscore, static and global vars always start with an 
uppercase letter, and all local vars and parameters start with a lowercase 
letter.

***

Even if we use .bar() instead of just bar() when calling from within a `with` 
block, I still don't like it. How many keystrokes are we sparing? If the 
variable has two letters, e.g. it's named `br`, we have `with(br){` (9 
characters, 1 newline) and `}` (1 character, 1 newline) compared to 2 
keystrokes for each time you may omit `br`. If you count the newlines as 
characters, you have to use the variable br 7 times in order for the `with` 
statement to pay off.

***

Using { $0.bar() } is interesting too. But why?? Just give the variable a short 
name, call it x0, for example, and you are saving even more keystrokes.

***

IMHO, saving sourecode-bits is not everything; readable code is everything. 
Therefore, a -1 from me.

-Michael

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

Re: [swift-evolution] [Proposal] mapValues

[Dave Abrahams via swift-evolution]

on Tue Apr 12 2016, Jonathan Hull  wrote:

> I would really like to see something like the following added to the standard
> library:
>
> extension Dictionary {
>
> func mapValues(transform:(Key,Value)->U)->[Key:U] {
> var output:[Key:U] = [:]
> for (k,v) in self {
> output[k] = transform(k,v)
> }
> return output
> }
>
> }
>
> It comes up enough that I have had to add it to pretty much every one of my
> projects. I also don’t feel comfortable adding it to my frameworks, since I
> figure a lot of people are also adding something like this to their projects,
> and I don’t want to cause a conflict with their version. Prime candidate for 
> the
> standard library.
>
> I like calling it ‘mapValues' as opposed to providing an override for map, 
> since
> it makes the specific behavior more clear. I would expect ‘map' to possibly 
> map
> the keys as well (though there are issues where the new keys overlap). I 
> suppose
> you could just have a bunch of overrides for map if the compiler becomes good
> enough at differentiating return types: (Value)->(Value), (Key,Value)->Value,
> (Key, Value)->(Key,Value)

I agree that we need a way to do this, and was surprised when what I
tried didn't work.  This should work:

  Dictionary(d.lazy.map { (k, v) in (k, transform(v)) })

We should have a proposal that makes the constructor work* if we don't
already have one.

I'm inclined against building specialized variants of basic algorithms
into particular collections, though.  Could be talked out of it if the
use-case is strong enough.

--

* Only question: does this need a label, e.g. 

Dictionary(uniquingKeys: d.lazy.map { (k, v) in (k, transform(v)) })

  to denote that it's lossy?
-- 
Dave

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

[swift-evolution] [Deferred] SE-0058 Allow Swift types to provide custom Objective-C representations

[Joe Groff via swift-evolution]

The review of SE-0058 "Allow Swift types to provide custom Objective-C 
representations" ran from April 4...11, 2016. The proposal has been deferred 
from Swift 3. We agree that it would be valuable to give library authors the 
ability to bridge their own types from Objective-C into Swift using the same 
mechanisms as Foundation. However, we lack the confidence and implementation 
experience to commit to `_ObjectiveCBridgeable` in its current form as public 
API. In its current form, as its name suggests, the protocol was designed to 
accommodate the specific needs of bridging Objective-C object types to Swift 
value types. In the future, we may want to bridge with other platforms, 
including C++ value types or other object systems such as COM, GObject, JVM, or 
CLR. It isn't clear at this point whether these would be served by a 
generalization of the existing mechanism, or by bespoke bridging protocols 
tailored to each case. This is a valuable area to explore, but we feel that it 
is too early at this point to accept our current design as public API.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Gwendal Roué via swift-evolution]

> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> To me, compound names for closure properties and satisfying property 
> requirements with methods aren't hacks, they're missing features we ought to 
> support anyway.

Hello,

I may have missed the point, but it looks like you say that optional delegate 
methods could be replaced by closures.

If this is the case, then I recently faced an issue with closures as a 
replacement for optional delegate methods, and the issue was with the 
responsibility of weak reference of the delegate.

So instead of:

protocol CDelegate : class { func f() }
class C {
weak var delegate: CDelegate?
func doIt() {
delegate?.f()
}
}

We’d have:

class C {
var f: (() -> ())?
func doIt() {
f?()
}
}

Is it what you were referring to?

If so, then the trouble is for the code that sets the closure. It has to 
perform the weak self/strongSelf dance:

c = C()
c.f = { [weak self] in
guard let strongSelf = self else { return }
strongSelf….
}

I find it awfully awfully heavy. The caller has 1. to remember about weakifying 
self, and 2. extract strongSelf from the weak self.

Of course, if you were talking about something else, you can discard my comment.

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

Re: [swift-evolution] Crypto routines as part of the core library

[David Waite via swift-evolution]

I don’t know if we need a boost-like parent project in order to start building 
core code to be brought for inclusion.

I think success will naturally bring such a project structure - people seeking 
a curated and integrated set of frameworks to get common functionality. 

-DW

> On Apr 13, 2016, at 12:16 PM, Tino Heth via swift-evolution 
>  wrote:
> 
>> This seems like a great candidate for a library that could be developed in 
>> the community and then possibly brought into Corelibs in a future version
> true — but sadly, there seems to be either no interest or manpower for a 
> boost-like infrastructure…
> Like many other fundamental topics, I don't think crypto belongs to the 
> stdlib, but none the less, there should be a standard library for 
> encryption/hashing.
> ___

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

Re: [swift-evolution] [Proposal] mapValues

[Jacob Bandes-Storch via swift-evolution]

To adhere to the API Design Guidelines, I think it should be named
"mappingValues", right?

On Wed, Apr 13, 2016 at 4:23 AM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> As for mapKeys and many values into a single key. I believe we should have
> a choice - do we expect multiply values for the same key or not. Just like
> "+" and integer overflow : by default it raises the error, but if "&+" - we
> expect the overflow. I can imagine situations when it is ok for me to have
> different values for the same key(if I don't care which of values should be
> for that key in result dictionary).
> So my proposal is some additional mapKey(allowMultiplyValues: true) {...}
> or in any other form/name.
>
> On 13.04.2016 13:38, Ross O'Brien via swift-evolution wrote:
>
>> +1 on mapValues.
>>
>> DictionaryLiteral already throws an exception if it includes duplicate
>> keys, so I'd expect mapKeys to throw an error if multiple source keys
>> mapped to the same destination key.
>>
>> On Wed, Apr 13, 2016 at 11:28 AM, Miguel Angel Quinones via
>> swift-evolution
>> > wrote:
>>
>> I'm +1 for adding mapValues. Very useful functionality and trivial to
>> implement.
>>
>>  > > I.e. I suggest to implement and mapKeys() also. It could be also
>> useful in some situations.
>> > `mapKeys` is much more dangerous, because you could end up mapping
>> many values into a single key. You kind of need to combine the values
>> somehow. Perhaps:
>> >
>> > extension Dictionary {
>>  > func mapValues__(_ valueTransform: @noescape Value throws
>> ->OutValue) rethrows ->[Key: OutValue] { … }
>>  >
>>  > func mapKeys__(_ keyTransform: @noescape Key throws ->OutKey)
>> rethrows ->[OutKey: [Value]] { … }
>> >
>> > // Possibly flatMap variants, too?
>> > }
>> >
>> > extension Dictionary where Value: Sequence {
>>  > func reduceValues__(_ initial: OutValue, combine: @noescape
>> (OutValue, Value.Iterator.Element) throws ->OutValue) rethrows ->[Key:
>> OutValue] {
>> > return mapValues { $0.reduce(initial, combine: combine) }
>> > }
>> > }
>> >
>> > Which you would end up using like this:
>> >
>> > let wordFrequencies: [String: Int] = …
>> > let firstLetterFrequencies: [Character: Int] =
>> wordFrequencies.mapKeys { $0.characters.first! }.reduceValues(0, combine: +)
>> >
>> > --
>> > Brent Royal-Gordon
>> > Architechies
>> >
>> >
>> >
>> >__
>>
>> --
>> Miguel Angel Quinones
>>
>> ___
>> 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] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

> On Apr 11, 2016, at 10:30 AM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> One could perhaps work around (a), (b), and (d) by allowing compound 
>>> (function-like) names like tableView(_:viewFor:row:) for properties, and 
>>> work around (c) by allowing a method to satisfy the requirement for a 
>>> read-only property, but at this point you’ve invented more language hacks 
>>> than the existing @objc-only optional requirements. So, I don’t think there 
>>> is a solution here.
>> 
>> To me, compound names for closure properties and satisfying property 
>> requirements with methods aren't hacks, they're missing features we ought to 
>> support anyway. I strongly prefer implementing those over your proposed 
>> solution. It sounds to me like a lot of people using optional protocol 
>> requirements *want* the locality of control flow visible in the caller, for 
>> optimization or other purposes, and your proposed solution makes this 
>> incredibly obscure and magical.
> 
> Do you have the same thought for optional closure properties?  If so and 
> heightForRow was an optional closure property it would satisfy all use cases 
> elegantly.  It could have a default implementation that returns nil.  When 
> non-uniform heights are required a normal method implementation can be 
> provided.  Delegates that have uniform row heights some of the time, but not 
> all of the time, would also be supported by implementing the property.

There are still some issues here:

1) It doesn’t handle optional read/write properties at all, because the setter 
signature would be different. Perhaps some future lens design would make this 
possible. For now, the workaround would have to be importing the setter as a 
second optional closure property, I guess. (The current system is similarly 
broken).

2) For an @objc protocol, you won’t actually be able to fully implement the 
optional closure property with a property of optional type, because “return 
nil” in the getter is not the same as “-respondsToSelector: returns false”. 
Indeed, the getter result type/setter parameter type should be non-optional, so 
we would (at best) need a special rule that optional closure properties of 
@objc protocols can only be implemented by non-optional properties of closure 
type or by methods.

> If we decide to favor this approach it would be really nice to be able to 
> import Cocoa delegate protocols this way.  Is that something that might be 
> feasible?


Yes. If we favor this approach, it should be fairly direct to make imported 
Objective-C protocols work this way.

- Doug

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

Re: [swift-evolution] What about a VBA style with Statement?

[Vladimir.S via swift-evolution]

But in case of struct instance constant - we have a problem:

struct A {
var x = 1
var y = 2
}

let a1 = A()

with (a1) {
print($0.x)
$0.y = 10
}

- this will be compiled without errors/warnings, but yes - there will be 
runtime error. I'm sure this is not what we need from Swift. And so, this 
"with" function can not be a 100% replacement for special language 
construction. So, all, please provide your opinion on this proposal and I 
believe we should move it forward.



On 13.04.2016 18:51, Erica Sadun via swift-evolution wrote:



On Apr 13, 2016, at 7:50 AM, Benzi via swift-evolution
> wrote:

The closest right now you can achieve would be:

func with(item:T, apply:(T)->Void) {
apply(item)
}


let label = UILabel()
label.highlighted // defaults to false

with(label) {
$0.highlighted = true
}

label.highlighted // is now true


As a reference type, you can just go ahead and assign:

letlabel  = UILabel()
label.highlighted= true

-- E




___
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] Crypto routines as part of the core library

[Travis Beech via swift-evolution]

So what are developers doing then to make sure their apps are secure? Are they 
just not adopting Swift, or just relying on the bridging of CommonCrypto to 
fill the gaps?

Travis Beech | Principal Developer | Unwired Revolution | c: 1 (209) 535-5357
Optimizing Operations for Mobile and Distributed Systems








On 4/13/16, 9:16 AM, "Tino Heth" <2...@gmx.de> wrote:

>> This seems like a great candidate for a library that could be developed in 
>> the community and then possibly brought into Corelibs in a future version
>true — but sadly, there seems to be either no interest or manpower for a 
>boost-like infrastructure…
>Like many other fundamental topics, I don't think crypto belongs to the 
>stdlib, but none the less, there should be a standard library for 
>encryption/hashing.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Crypto routines as part of the core library

[Tino Heth via swift-evolution]

> This seems like a great candidate for a library that could be developed in 
> the community and then possibly brought into Corelibs in a future version
true — but sadly, there seems to be either no interest or manpower for a 
boost-like infrastructure…
Like many other fundamental topics, I don't think crypto belongs to the stdlib, 
but none the less, there should be a standard library for encryption/hashing.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop

[Vladimir.S via swift-evolution]

as @Erica just noted, we probably will have this in Swift3 :

for i in (1...10).striding(by: 3) {..}
for i in (1...10).striding(by: -3) {..}

But.. compare how the next is more clear and nice looking, has less noise, 
how faster this will be typed.. :


for i in 1...10 by 3 {...}
for i in 1...10 by -3 {...}

just beautiful :-)
My opinion: this .striding is about Range type. Range type is used in many 
places, not just in for-in loop. It is important to have handy and clear 
methods for Range. But. If we are talking about loop - why(why?) can't we 
have such a great syntax for such a common loop task? It is explicit, it 
can generate the same (1...10).striding(by: 3) code internally.

IMO I'd love to have such syntax in Swift for for-in loop

On 13.04.2016 17:52, Hans Huck via swift-evolution wrote:

Rationale:
Swift's For-In-loop is fine, as long as you don't need an iteration step
size other than 1/-1, in which case it becomes unexpectedly inconsistent
and unwieldy.
for i in 1...10
for i in reverse(10...1)
for i in stride(from:1, through:10, by:3)
or even
for i in 1.stride(through:10, by:3)
The above sequence is not only confusing for teaching purposes/beginners
(first lesson: protocols. really?), but also unnecessarily bulky for
everyday use. It's a For-loop, one of the most basic and frequently used
structures in any language -- please let's make it pithy.

Comparison:
Currently, even the C-style For-loop we are just about to get rid of could
be argued to be more concise and consistent, but significantly more so are
the likes of
# Python
for i in range(1, 10, 3):
-- Lua
for i = 1, 10, 3
' Basic
for i = 1 to 10 step 3
(* Modula-2 *)
for i := 1 to 10 by 3
// Chapel
for i in 1..10 by 3
or any other remotely relevant non-C-style language that allows For-loops
with an altered step size.
While there are other issues like having to use reverse(1...10) instead of
simply 10...1, (which compiles, but doesn't run, even when using literals
-- why?) none of it goes against the grain as much as being forced to type
out stride(boiboiboilerplate) for a simple iteration.

Suggestion(s):
A) Add keyword "by" as syntactic sugar, used as in Modula/Chapel (and tip
our hat to Algol 68):
// Swift
for i in 1...10 by 3
for i in reverse(1...10) by -3
or even better yet (if feasible):
B)
for i in 1...10 by 3
for i in 10...1 by -3

Please comment, and thanks everyone for reading.
-- Hans


___
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] What about a VBA style with Statement?

[Erica Sadun via swift-evolution]

> On Apr 13, 2016, at 9:34 AM, Kurt Werle via swift-evolution 
>  wrote:
> 
> I've always thought that the with construct is not a good idea.  It seems to 
> me that the moment you want to use with it indicates that you are getting too 
> much into some other classes business; shouldn't that class deal with this?  
> Why are you exposing/integrating so much of some other class's logic?  Maybe 
> there should be a method that does all this, or maybe a custom struct that 
> passes all the appropriate information...
> 
> Yeah, there are exceptions - always.  But for the most part I'm not a fan.
> 
> Kurt

The biggest advantage of the with pattern IMO is Cocoa initializers. It 
provides a more unified 
initialization scope. Instead of:

let questionLabel = UILabel()
questionLabel.textAlignment = .Center
questionLabel.font =  UIFont(name:"DnealianManuscript", size: 72)
questionLabel.text = currentQuestion.text
questionLabel.numberOfLines = 0

You get:

let questionLabel2 = with(UILabel()) {
$0.textAlignment = .Center
$0.font =  UIFont(name:"DnealianManuscript", size: 72)
$0.text = currentQuestion.text
$0.numberOfLines = 0
}

You also have the option to customize a Value type before assigning it to a 
constant or to base
a new value constant on a copy of an existing value constant:

struct Foo { var (a, b, c) = ("a", "b", "c") }
var f = with(Foo()) { $0.a = "X" }
print(f) // Foo(a: "X", b: "b", c: "c")

I personally would love to see a Swift construct that created a scope with 
`self` defined so the
awkward `$0.` prefixes could be discarded.

-- E, who may have brought up this topic once or twice before on this list

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

Re: [swift-evolution] Crypto routines as part of the core library

[Travis Beech via swift-evolution]

With the focus these days on writing secure applications it seems building this 
functionality into the language would be pretty high on the list. These are 
common API's found in modern languages and it would be nice to not have to use 
hackish techniques like bridging into CommonCrypto to achieve this. 

Travis Beech  |  Principal Developer  |  Unwired Revolution  |  c: 1 (209) 
535-5357
Optimizing Operations for Mobile and Distributed Systems

On Apr 12, 2016, at 11:06 PM, Brent Royal-Gordon  wrote:

>> It would seem to me that common crypto routines should become part of the 
>> core Swift libraries without having to rely on unknown third party libraries 
>> or bridging into the C based CommonCrypto lib.
> 
> This seems like a great candidate for a library that could be developed in 
> the community and then possibly brought into Corelibs in a future version, 
> but I strongly suspect it'll be considered out of scope for Swift 3.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Tony Parker via swift-evolution]

> On Apr 12, 2016, at 3:43 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> Thanks for your review, Tony!
> 
> on Mon Apr 11 2016, Tony Parker  > wrote:
> 
>>> On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "A New Model for Collections and Indices" begins now and runs 
>>> through April 18th. The proposal is available here:
>> 
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.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.
>>> 
>>> 
>>> 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?
>> 
>> I agree with the general direction and scope of the proposal, but I
>> think the names could use some changes. Specifically, I don’t think
>> the fallback to ‘form’ is required. 
> 
> It's not a fallback whatsoever.  The updated guidelines referenced from
> https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
>  
> 
> (which was accepted this morning; announcement forthcoming) make the
> “form” prefix a first-class citizen that one chooses based on the
> noun-ness of the underlying operation.  Furthermore, *treating*
> “formXXX” as a fallback and avoiding it will continue to strengthen the
> sense that it's not something we should normally use, leading to more
> naming arguments in the future.  It's a strong guideline and as long as
> we have it, we shouldn't be afraid to apply it, thereby increasing
> uniformity and predictability.
> 
> [To all my fellow “InPlace” lovers out there: yes, another guideline
> might be more optimal, but this is the guideline we have/can get].
> 

In other cases, the mutating pair of methods refer to the receiver, not the 
argument. 

x = y.union(z) // new value x
y.formUnion(z) // mutates y, not z

x = y.successor(z) // new value x
y.formSuccessor(z) // mutates z (or replaces), not y

I think using the form prefix here will confuse this case with the others, when 
they are meaningfully different.

>> It would be a significant readability improvement to use a meaningful
>> verb to describe the action of altering the argument. The methods that
>> create new indices probably need a label on the first argument,
>> because otherwise it looks as if the IndexDistance is what is
>> described by ‘index’.
>> 
>> Proposed:
>> 
>>  func successor(of i: Index) -> Index
>>  func formSuccessor(i: inout Index)
>> 
>> Instead, I suggest:
>> 
>>  func successor(of i : Index) -> Index
>>  func advance(i: inout Index)
> 
> Why is that an improvement?  It loses the correspondence between the
> operations, which are still a mutating/nonmutating pair.  What's it got
> to recommend it?  I have the same question about all of the suggestions
> below.

It’s an improvement because it is much easier to read and understand what it 
means. The phrase “form successor” only makes sense if you dive into the naming 
guidelines to see why we have the “form” prefix in the first place. Plus, as I 
said, the form prefix implies a mutation of the wrong argument.

> 
>> Proposed:
>> 
>>  func index(n: IndexDistance, stepsFrom i: Index) -> Index
>>  func index(n: IndexDistance, stepsFrom i: Index, limitedBy limit: Index) -> 
>> Index
>>  func formIndex(n: IndexDistance, stepsFrom i: inout Index)
>>  func formIndex(n: IndexDistance, stepsFrom i: inout Index, limitedBy limit: 
>> Index)
>> 
>> Suggested (taking into account Nate’s suggestion of reversing the order):
>> 
>>  func index(startingAt i: Index, movedBy n: IndexDistance) -> Index
>>  func index(startingAt i: Index, movedBy n: IndexDistance, limitedBy limit: 
>> Index) -> Index
> 
> I find Nate Cook's concerns about the use of “index” here (a mental
> clash with unrelated methods having the same basename) especially
> convincing.  So I think I want to look for other names for these.
> 
>> 
>>  func move(i : inout Index, by n: IndexDistance) 
>>  func move(i : inout Index, by n: IndexDistance, limitedBy limit: Index)
>> 
>> Proposed:
>> 
>>  func predecessor(of i: Index) -> Index
>>  func formPredecessor(i: inout Index)
>> 
>> Suggested:
>> 
>>  func predecessor(of i: Index) -> Index
>>  func reverse(i: inout Index)
>> 
>> I think reversing 

[swift-evolution] What about a VBA style with Statement?

[Benzi via swift-evolution]

The closest right now you can achieve would be:

func with(item:T, apply:(T)->Void) {
apply(item)
}


let label = UILabel()
label.highlighted // defaults to false

with(label) {
$0.highlighted = true
}

label.highlighted // is now true
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] What about a VBA style with Statement?

[Kurt Werle via swift-evolution]

I've always thought that the with construct is not a good idea.  It seems
to me that the moment you want to use with it indicates that you are
getting too much into some other classes business; shouldn't that class
deal with this?  Why are you exposing/integrating so much of some other
class's logic?  Maybe there should be a method that does all this, or maybe
a custom struct that passes all the appropriate information...

Yeah, there are exceptions - always.  But for the most part I'm not a fan.

Kurt
-- 
k...@circlew.org
http://www.CircleW.org/kurt/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] What about a VBA style with Statement?

[Vladimir.S via swift-evolution]

+1 on statement vs lexical scope. additionally { $0.something ... } is more 
explicit than just .something.


On 13.04.2016 17:36, Taras Zakharko via swift-evolution wrote:

We had this kind of proposal earlier, didn’t seem to be very well received. I 
still think it would be a useful thing, but I’d do it as a statement (extension 
of do) that introduces new lexical  scope (similar to self)

— Taras


On 13 Apr 2016, at 16:25, Sean Heber via swift-evolution 
 wrote:

This pair works pretty well, too, if you don’t mind free functions:

func with(inout this: T, @noescape using: inout T->Void) { using() }
func with(this: T, @noescape using: T->Void) { using(this) }

It works either with classes or mutable structs if you call it correctly and 
the type doesn’t matter.

l8r
Sean



On Apr 13, 2016, at 9:17 AM, Radosław Pietruszewski via swift-evolution 
 wrote:

It can be (more-or-less) solved in library code today:

extension NSObjectProtocol {
public func with(@noescape fn: Self -> Void) -> Self {
fn(self)
return self
}
}

This way, you can do, on NSObjects:

textLabel.with {
$0.textAlignment = .Left
$0.textColor = .darkTextColor()
}

I love this pattern.

You can also make it a function to make it work with any value of any kind (it 
will then take form of `with(foo) { …}`).

Ideally, if you could write a universal extension (something like `extension 
Any`), you could just add this behavior, with method syntax, to everything.

— Radek


On 13 Apr 2016, at 15:15, 李海珍 via swift-evolution  
wrote:

I recently learned some VBA and I found a very conveniently `with` statement.

`with` statement can be helpful to set property for UIKit instance.

for instance a UILabel instance `textLabel` ,with `with` statement we can set 
UILabel property like this



```swift

with textLabel{

.textAlignment = .Left

.textColor = UIColor.darkTextColor()

.font = UIFont.systemFontOfSize(15)

}

```

___
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


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

Re: [swift-evolution] What about a VBA style with Statement?

[Radosław Pietruszewski via swift-evolution]

> On 13 Apr 2016, at 16:47, Vladimir.S  wrote:
> 
> Than you for sharing this method. So, do you suggest to not have this "with" 
> construction in Swift just because we *can* implement the same behavior by 
> using some workarounds/hacks?
> 
> I.e. do you support this proposal or don't?
> Do you agree that such built-in feature will be very useful and make our 
> programming live a little better/easier?

I’m -1, at least in the foreseeable future. I do agree that this is a useful 
construct, but if I can do it in library code, paying only a small price for 
this, I’d prefer Swift to grow better in places that a library *can’t* fix.

> 
> I strongly believe that if such feature is really useful and handy, if it is 
> explicit and if it is clearly showing in code what we are doing - we most 
> likely want to have this feature as part of language rather than possibility 
> to use some workaround to implement it.
> 
> With your suggestion, how to deal with two separate classes that have no 
> common protocol? I.e.
> class A { .. }; class B {..};
> Should we conform them to some protocol or create extension of each just to 
> have this "with" feature? Don't think so.

No — for now, it’s best to use a free function for now. And, like I mentioned, 
universal conformances could allow this to be easily added to all types — and 
so I’d focus on pushing *that* proposal.

> 
> On 13.04.2016 17:17, Radosław Pietruszewski via swift-evolution wrote:
>> It can be (more-or-less) solved in library code today:
>> 
>>extension NSObjectProtocol {
>> public func with(@noescape fn: Self -> Void) -> Self {
>> fn(self)
>> return self
>> }
>>}
>> 
>> 
>> This way, you can do, on NSObjects:
>> 
>>textLabel.with {
>> 
>>$0.textAlignment = .Left
>> 
>>$0.textColor = .darkTextColor()
>> 
>>}
>> 
>> 
>> I love this pattern.
>> 
>> You can also make it a function to make it work with any value of any kind
>> (it will then take form of `with(foo) { …}`).
>> 
>> Ideally, if you could write a universal extension (something like
>> `extension Any`), you could just add this behavior, with method syntax, to
>> everything.
>> 
>> — Radek
>> 
>>> On 13 Apr 2016, at 15:15, 李海珍 via swift-evolution
>>>  
>>> >> 
>>> wrote:
>>> 
>>> I recently learned some VBA and I found a very conveniently `with` 
>>> statement.
>>> 
>>> `with` statement can be helpful to set property for UIKit instance.
>>> 
>>> for instance a UILabel instance `textLabel` ,with `with` statement we can
>>> set UILabel property like this
>>> 
>>> 
>>> ```swift
>>> 
>>> with textLabel{
>>> 
>>> .textAlignment= .Left
>>> 
>>> .textColor= UIColor.darkTextColor()
>>> 
>>> .font= UIFont.systemFontOfSize(15)
>>> 
>>> }
>>> 
>>> ```
>>> 
>>> ___
>>> 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] What about a VBA style with Statement?

[Vladimir.S via swift-evolution]

Yes, it really looks like language construction, and I like this approach.
with (some) {
  $0... = ...
}

But should many of us copy-paste these functions in each module/project or 
this is very handful feature that we want to have in our language? What do 
you think about the proposal?


Actually I think it is even OK if such functions will be in standard lib, 
i.e. without intruducing new language construct, and we can use them 
out-of-box to have 'with' functionality.


On 13.04.2016 17:25, Sean Heber via swift-evolution wrote:

This pair works pretty well, too, if you don’t mind free functions:

func with(inout this: T, @noescape using: inout T->Void) { using() }
func with(this: T, @noescape using: T->Void) { using(this) }

It works either with classes or mutable structs if you call it correctly and 
the type doesn’t matter.

l8r
Sean



On Apr 13, 2016, at 9:17 AM, Radosław Pietruszewski via swift-evolution 
 wrote:

It can be (more-or-less) solved in library code today:

extension NSObjectProtocol {
 public func with(@noescape fn: Self -> Void) -> Self {
 fn(self)
 return self
 }
}

This way, you can do, on NSObjects:

textLabel.with {
$0.textAlignment = .Left
$0.textColor = .darkTextColor()
}

I love this pattern.

You can also make it a function to make it work with any value of any kind (it 
will then take form of `with(foo) { …}`).

Ideally, if you could write a universal extension (something like `extension 
Any`), you could just add this behavior, with method syntax, to everything.

— Radek


On 13 Apr 2016, at 15:15, 李海珍 via swift-evolution  
wrote:

I recently learned some VBA and I found a very conveniently `with` statement.

`with` statement can be helpful to set property for UIKit instance.

for instance a UILabel instance `textLabel` ,with `with` statement we can set 
UILabel property like this



```swift

with textLabel{

.textAlignment = .Left

.textColor = UIColor.darkTextColor()

.font = UIFont.systemFontOfSize(15)

}

```

___
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] What about a VBA style with Statement?

[Vladimir.S via swift-evolution]

Than you for sharing this method. So, do you suggest to not have this 
"with" construction in Swift just because we *can* implement the same 
behavior by using some workarounds/hacks?


I.e. do you support this proposal or don't?
Do you agree that such built-in feature will be very useful and make our 
programming live a little better/easier?


I strongly believe that if such feature is really useful and handy, if it 
is explicit and if it is clearly showing in code what we are doing - we 
most likely want to have this feature as part of language rather than 
possibility to use some workaround to implement it.


With your suggestion, how to deal with two separate classes that have no 
common protocol? I.e.

class A { .. }; class B {..};
Should we conform them to some protocol or create extension of each just to 
have this "with" feature? Don't think so.


On 13.04.2016 17:17, Radosław Pietruszewski via swift-evolution wrote:

It can be (more-or-less) solved in library code today:

extension NSObjectProtocol {
 public func with(@noescape fn: Self -> Void) -> Self {
 fn(self)
 return self
 }
}


This way, you can do, on NSObjects:

textLabel.with {

$0.textAlignment = .Left

$0.textColor = .darkTextColor()

}


I love this pattern.

You can also make it a function to make it work with any value of any kind
(it will then take form of `with(foo) { …}`).

Ideally, if you could write a universal extension (something like
`extension Any`), you could just add this behavior, with method syntax, to
everything.

— Radek


On 13 Apr 2016, at 15:15, 李海珍 via swift-evolution
> wrote:

I recently learned some VBA and I found a very conveniently `with` statement.

`with` statement can be helpful to set property for UIKit instance.

for instance a UILabel instance `textLabel` ,with `with` statement we can
set UILabel property like this


```swift

with textLabel{

.textAlignment= .Left

.textColor= UIColor.darkTextColor()

.font= UIFont.systemFontOfSize(15)

}

```

___
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] [Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop

[Hans Huck via swift-evolution]

Rationale:

 

Swift's For-In-loop is fine, as long as you don't need an iteration step size other than 1/-1, in which case it becomes unexpectedly inconsistent and unwieldy.

 

for i in 1...10
for i in reverse(10...1)
for i in stride(from:1, through:10, by:3)
or even
for i in 1.stride(through:10, by:3)

 

The above sequence is not only confusing for teaching purposes/beginners (first lesson: protocols. really?), but also unnecessarily bulky for everyday use. It's a For-loop, one of the most basic and frequently used structures in any language -- please let's make it pithy.

 


Comparison:

 

Currently, even the C-style For-loop we are just about to get rid of could be argued to be more concise and consistent, but significantly more so are the likes of

 

# Python
for i in range(1, 10, 3):

 

-- Lua
for i = 1, 10, 3

 

' Basic
for i = 1 to 10 step 3

 

(* Modula-2 *)
for i := 1 to 10 by 3

 

// Chapel
for i in 1..10 by 3

 

or any other remotely relevant non-C-style language that allows For-loops with an altered step size.

 

While there are other issues like having to use reverse(1...10) instead of simply 10...1, (which compiles, but doesn't run, even when using literals -- why?) none of it goes against the grain as much as being forced to type out stride(boiboiboilerplate) for a simple iteration.

 


Suggestion(s):

 

A) Add keyword "by" as syntactic sugar, used as in Modula/Chapel (and tip our hat to Algol 68):

 

// Swift
for i in 1...10 by 3
for i in reverse(1...10) by -3

 

or even better yet (if feasible):

 

B)

for i in 1...10 by 3
for i in 10...1 by -3


Please comment, and thanks everyone for reading.

 

-- Hans

 

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

Re: [swift-evolution] What about a VBA style with Statement?

[Taras Zakharko via swift-evolution]

We had this kind of proposal earlier, didn’t seem to be very well received. I 
still think it would be a useful thing, but I’d do it as a statement (extension 
of do) that introduces new lexical  scope (similar to self)

— Taras

> On 13 Apr 2016, at 16:25, Sean Heber via swift-evolution 
>  wrote:
> 
> This pair works pretty well, too, if you don’t mind free functions:
> 
> func with(inout this: T, @noescape using: inout T->Void) { using() }
> func with(this: T, @noescape using: T->Void) { using(this) }
> 
> It works either with classes or mutable structs if you call it correctly and 
> the type doesn’t matter.
> 
> l8r
> Sean
> 
> 
>> On Apr 13, 2016, at 9:17 AM, Radosław Pietruszewski via swift-evolution 
>>  wrote:
>> 
>> It can be (more-or-less) solved in library code today:
>> 
>> extension NSObjectProtocol {
>>public func with(@noescape fn: Self -> Void) -> Self {
>>fn(self)
>>return self
>>}
>> }
>> 
>> This way, you can do, on NSObjects:
>> 
>> textLabel.with {
>>  $0.textAlignment = .Left
>>  $0.textColor = .darkTextColor()
>> }
>> 
>> I love this pattern.
>> 
>> You can also make it a function to make it work with any value of any kind 
>> (it will then take form of `with(foo) { …}`).
>> 
>> Ideally, if you could write a universal extension (something like `extension 
>> Any`), you could just add this behavior, with method syntax, to everything.
>> 
>> — Radek
>> 
>>> On 13 Apr 2016, at 15:15, 李海珍 via swift-evolution 
>>>  wrote:
>>> 
>>> I recently learned some VBA and I found a very conveniently `with` 
>>> statement.
>>> 
>>> `with` statement can be helpful to set property for UIKit instance.
>>> 
>>> for instance a UILabel instance `textLabel` ,with `with` statement we can 
>>> set UILabel property like this
>>> 
>>> 
>>> 
>>> ```swift
>>> 
>>> with textLabel{
>>> 
>>> .textAlignment = .Left
>>> 
>>> .textColor = UIColor.darkTextColor()
>>> 
>>> .font = UIFont.systemFontOfSize(15)
>>> 
>>> }
>>> 
>>> ```
>>> 
>>> ___
>>> 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] What about a VBA style with Statement?

[Sean Heber via swift-evolution]

This pair works pretty well, too, if you don’t mind free functions:

func with(inout this: T, @noescape using: inout T->Void) { using() }
func with(this: T, @noescape using: T->Void) { using(this) }

It works either with classes or mutable structs if you call it correctly and 
the type doesn’t matter.

l8r
Sean


> On Apr 13, 2016, at 9:17 AM, Radosław Pietruszewski via swift-evolution 
>  wrote:
> 
> It can be (more-or-less) solved in library code today:
> 
> extension NSObjectProtocol {
> public func with(@noescape fn: Self -> Void) -> Self {
> fn(self)
> return self
> }
> }
> 
> This way, you can do, on NSObjects:
> 
> textLabel.with {
>   $0.textAlignment = .Left
>   $0.textColor = .darkTextColor()
> }
> 
> I love this pattern.
> 
> You can also make it a function to make it work with any value of any kind 
> (it will then take form of `with(foo) { …}`).
> 
> Ideally, if you could write a universal extension (something like `extension 
> Any`), you could just add this behavior, with method syntax, to everything.
> 
> — Radek
> 
>> On 13 Apr 2016, at 15:15, 李海珍 via swift-evolution 
>>  wrote:
>> 
>> I recently learned some VBA and I found a very conveniently `with` statement.
>> 
>> `with` statement can be helpful to set property for UIKit instance.
>> 
>> for instance a UILabel instance `textLabel` ,with `with` statement we can 
>> set UILabel property like this
>> 
>> 
>> 
>> ```swift
>> 
>> with textLabel{
>> 
>> .textAlignment = .Left
>> 
>> .textColor = UIColor.darkTextColor()
>> 
>> .font = UIFont.systemFontOfSize(15)
>> 
>> }
>> 
>> ```
>> 
>> ___
>> 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] What about a VBA style with Statement?

[Radosław Pietruszewski via swift-evolution]

It can be (more-or-less) solved in library code today:

extension NSObjectProtocol {
public func with(@noescape fn: Self -> Void) -> Self {
fn(self)
return self
}
}

This way, you can do, on NSObjects:

textLabel.with {
$0.textAlignment = .Left
$0.textColor = .darkTextColor()
}

I love this pattern.

You can also make it a function to make it work with any value of any kind (it 
will then take form of `with(foo) { …}`).

Ideally, if you could write a universal extension (something like `extension 
Any`), you could just add this behavior, with method syntax, to everything.

— Radek

> On 13 Apr 2016, at 15:15, 李海珍 via swift-evolution  
> wrote:
> 
> I recently learned some VBA and I found a very conveniently `with` statement.
> 
> `with` statement can be helpful to set property for UIKit instance.
> 
> for instance a UILabel instance `textLabel` ,with `with` statement we can set 
> UILabel property like this
> 
> 
> 
> ```swift
> 
> with textLabel{
> 
> .textAlignment = .Left
> 
> .textColor = UIColor.darkTextColor()
> 
> .font = UIFont.systemFontOfSize(15)
> 
> }
> 
> ```
> 
> ___
> 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] [Review] SE-0065 A New Model for Collections and Indices

[plx via swift-evolution]

> On Apr 13, 2016, at 5:34 AM, Haravikk  wrote:
> 
> 
>> On 13 Apr 2016, at 04:46, plx via swift-evolution 
>>  wrote:
>> 
>> Invalidation is hard and I wouldn’t want anything held up to try and find a 
>> solution first.
> 
> Oh I agree, that was partly my point though; while this proposal may leave us 
> with the "un-Swifty" issue of being unable to explicitly handle invalidation, 
> it should be possible to solve that later, i.e- this proposal does’t make us 
> any more vulnerable to that problem than we are now, but I definitely agree 
> that we could do with some kind of invalidation mechanism in future that 
> developers can actually implement or respond to. I guess I was more thinking 
> out loud about whether the problem affects the proposal or not, but I don’t 
> think that solving it will place any restrictions on the API as proposed, 
> definitely deserves a proposal of its own once the new indexing system is in 
> place though!

There was a design document linked in one of the earlier discussions that IIRC 
suggested some collections would want to maintain a "revision count” value, 
with their indices then holding a snapshot of that “revision count” at their 
time of creation.

For something like Array that’s a bit heavyweight.

“Invalidation" is also IMHO a bit under-defined without an associated “for 
what?”:

  var letters = [“a”, “b”, “c”, “d”, “e”]

  // indexOfB == 1
  let indexOfB = letters.indexOf(“b”)

  letters.insert(“z”, atIndex: indexOfB)

…is `index` invalid or not? IMHO it would depend on what you want to do with it.


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

Re: [swift-evolution] What about a VBA style with Statement?

[Vladimir.S via swift-evolution]

I like this idea.

In Delphi(Pascal) there is also such construction
with someVar do
 begin
 end;
And it is very handy and is used a lot (usually if you need to set/read a 
lot of properties of some object).


Additionally, I believe such construction prevents some possible mistakes 
with used variable name, especially if there is a similar-named variables 
in cod (sometimes because of code completion feature in editor) ex:

someVar1 = ...
someVar1

someVar2 = ..
someVar2
someVar1...  << mistake
someVar2...

and if "with" construction were here:

with someVar2 {
  .some...
  var a = .another
  etc
}

But the problem with "with" in Delphi is that it is not explicit what 
method/property belongs to that someVar and what doesn't belong.
In Swift, such construction should force us to somehow be explicit 
regarding what methods/props belongs to that someVar instance. Seems like 
"dot" syntax looks OK.


Don't know if that could be implemented in Swift technically.

On 13.04.2016 16:15, 李海珍 via swift-evolution wrote:

I recently learned some VBA and I found a very conveniently `with` statement.

`with` statement can be helpful to set property for UIKit instance.

for instance a UILabel instance `textLabel` ,with `with` statement we can
set UILabel property like this


```swift

with textLabel{

.textAlignment= .Left

.textColor= UIColor.darkTextColor()

.font= UIFont.systemFontOfSize(15)

}

```



___
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] What about a VBA style with Statement?

[李海珍 via swift-evolution]

I recently learned some VBA and I found a very conveniently `with`
statement.

`with` statement can be helpful to set property for UIKit instance.

for instance a UILabel instance `textLabel` ,with `with` statement we can
set UILabel property like this


```swift

with textLabel{

.textAlignment = .Left

.textColor = UIColor.darkTextColor()

.font = UIFont.systemFontOfSize(15)

}

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

Re: [swift-evolution] [Proposal] Safer half-open range operator

[Vladimir.S via swift-evolution]

Is it really great to have a[a.indices.clamped(to: 0 ..< 5)]
instead of a clear a[truncate: 0 ..< 5] ?
and if it is not "a" but "arrayOfSomeValues" we have
arrayOfSomeValues[arrayOfSomeValues.indices.clamped(to: 0 ..< 5)]
Don't feel this is nice.

Is it really so wrong to have additional(to "direct" functions like 
"indices.clamped" ) handy and nice-looking methods/subscripts in language?


IMO we all want to have great language. It should be great to code in such 
language. Is it great and enjoyable to have strange long construction 
instead of handy,clear and explicit expression?
Why don't improve the language in all possible area where we can improve 
it? I believe we should improve.


On 13.04.2016 14:09, Pyry Jahkola via swift-evolution wrote:

On 11 Apr 2016, at 15:23, Luis Henrique B. Sousa via swift-evolution
> wrote:

leta =[1,2,3]
letb =a[0..<5]
print(b)


In the swift-3-indexing-model branch
,
you can /clamp/ a range just like you could clamp intervals in Swift 2. So
the following will work in the way you preferred:

 let b = a[a.indices.clamped(to: 0 ..< 5)]

It was suggested to extend `Collection` with a subscript like `a[safe: 0
..< 5]` which resembles the current subsequence subscript
.
 Alternatively,
we could bring collections even closer to ranges by extending them with the
equivalent `.clamped(to:)` method:

 let b = a.clamped(to: 0 ..< 5) // "safe" subsequence

— Pyry



___
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] Safer half-open range operator

[Vladimir.S via swift-evolution]

The problem the "a[i &..< j]" is trying to solve is to allow us to work 
with array bounds without errors, even if i/j is incorrect, when we 
explicitly allows this.


As for your question, yes, it seems like there is a problem :-)
"i &..< j" should become a new Range. But such range knows nothing about 
array and its bounds. Probably such operator is not the best idea.


It seems I'd prefer in this case some kind of a[truncate: -1..<6] and 
probably a[safe: -1..<6] - which returns nil if range is incorrect.

So, in this case we'll have these methods and behavior:
a=[1,2,3]
a[-1..<6] - raises runtime error
a[truncate: -1..<6] - produces [1,2,3]
a[safe: -1..<6] - produces nil (i.e [T]?)

Seems like very handy and explicit. Right behavior by default(raises 
error). Opinions?


On 13.04.2016 13:52, Maximilian Hünenberger via swift-evolution wrote:

Should this new operator form a new range? How can this range know about
the array's indices?

A while ago there was a proposal (unfortunately it was not discussed
enough) which introduced safe array indexing:

  array[safe: 3] // returns nil if index out of bounds

So another way to handle this issue would be to make another subscript like:

  array[truncate: -1...6]

Best regards
- Maximilian

Am 12.04.2016 um 01:21 schrieb Luis Henrique B. Sousa via swift-evolution
>:


The idea of having a new operator following the principles of overflow
operators looks great. Two distinct operators doing implicit and
explicitly might really be a good way to go; it would be concise and
wouldn't look like some magic happened behind the scenes. I'd like to
hear more opinions about it.

> what we'll have in case a[-1 &..< 5]? should this raise error or become
[0 ..< 3] ? I think, the latter.
I agree here, I'd choose the latter.

From my perspective, the behaviour I'm proposing is what a considerable
number of users expect, especially if coming from other languages that
follow that path. Of course I'm not comparing languages here, but
considering the Swift principles of being a safer language, in my opinion
we'd rather have a partial slice than a crash in execution time (when the
user is not totally aware of it).

Many thanks for all your additions so far. It's really good to see that
these things are not set in stone yet.

- Luis

On Apr 11, 2016 4:21 PM, "Vladimir.S via swift-evolution"
> wrote:

+1 for the idea "in general". But I also think that explicit is
better than implicit, especially if we deal with possible errors.
Just like we work in Swift with integer overflow : '+' will generate
run time error, but saying &+ we point Swift that we know what we do.

but.. what we'll have in case a[-1 &..< 5]? should this raise error
or become [0 ..< 3] ? I think, the latter.

On 11.04.2016 17:02, Haravikk via swift-evolution wrote:

I like the idea in theory, but the question is; is it really safer to
return a result that the developer may not have wanted, versus an
error
indicating that a mistake may have been made? I wonder if perhaps
there
could be an alternative, such as a variation of the operator like so:

let b = a [0 &..< 5]// Equivalent to let b = a[0 ..< min(5,
a.endIndex)],
becomes let b = a[0 ..< 3]

I’m just not sure that we can assume that an array index out of
range error
is okay without some kind of indication from the developer, as
otherwise we
could end up returning a partial slice, which could end up
causing an error
elsewhere where the size of the slice is assumed to be 5 but isn’t.

On 11 Apr 2016, at 13:23, Luis Henrique B. Sousa via
swift-evolution

>> wrote:

This proposal seeks to provide a safer ..< (aka half-open
range operator)
in order to avoid **Array index out of range** errors in
execution time.

Here is my first draft for this proposal:

https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/-safer-half-open-range-operator.md

In short, doing that in Swift causes a runtime error:

leta =[1,2,3]
letb =a[0..<5]
print(b)

> Error running code:
> fatal error: Array index out of range

The proposed solution is to slice the array returning all
elements that
are below the half-open operator, even though the number of
elements is
lesser than the ending of the half-open operator. So the
example above
would return [1,2,3].
   

Re: [swift-evolution] [Proposal] mapValues

[Vladimir.S via swift-evolution]

As for mapKeys and many values into a single key. I believe we should have 
a choice - do we expect multiply values for the same key or not. Just like 
"+" and integer overflow : by default it raises the error, but if "&+" - we 
expect the overflow. I can imagine situations when it is ok for me to have 
different values for the same key(if I don't care which of values should be 
for that key in result dictionary).
So my proposal is some additional mapKey(allowMultiplyValues: true) {...} 
or in any other form/name.


On 13.04.2016 13:38, Ross O'Brien via swift-evolution wrote:

+1 on mapValues.

DictionaryLiteral already throws an exception if it includes duplicate
keys, so I'd expect mapKeys to throw an error if multiple source keys
mapped to the same destination key.

On Wed, Apr 13, 2016 at 11:28 AM, Miguel Angel Quinones via swift-evolution
> wrote:

I'm +1 for adding mapValues. Very useful functionality and trivial to
implement.

 > > I.e. I suggest to implement and mapKeys() also. It could be also
useful in some situations.
> `mapKeys` is much more dangerous, because you could end up mapping many 
values into a single key. You kind of need to combine the values somehow. Perhaps:
>
> extension Dictionary {
 > func mapValues__(_ valueTransform: @noescape Value throws
->OutValue) rethrows ->[Key: OutValue] { … }
 >
 > func mapKeys__(_ keyTransform: @noescape Key throws ->OutKey)
rethrows ->[OutKey: [Value]] { … }
>
> // Possibly flatMap variants, too?
> }
>
> extension Dictionary where Value: Sequence {
 > func reduceValues__(_ initial: OutValue, combine: @noescape
(OutValue, Value.Iterator.Element) throws ->OutValue) rethrows ->[Key:
OutValue] {
> return mapValues { $0.reduce(initial, combine: combine) }
> }
> }
>
> Which you would end up using like this:
>
> let wordFrequencies: [String: Int] = …
> let firstLetterFrequencies: [Character: Int] = wordFrequencies.mapKeys { 
$0.characters.first! }.reduceValues(0, combine: +)
>
> --
> Brent Royal-Gordon
> Architechies
>
>
>
>__

--
Miguel Angel Quinones

___
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] [Proposal] Safer half-open range operator

[Pyry Jahkola via swift-evolution]

> On 11 Apr 2016, at 15:23, Luis Henrique B. Sousa via swift-evolution 
>  wrote:
> let a = [1,2,3]
> let b = a[0..<5]
> print(b)
> 

In the swift-3-indexing-model branch 
,
 you can clamp a range just like you could clamp intervals in Swift 2. So the 
following will work in the way you preferred:

let b = a[a.indices.clamped(to: 0 ..< 5)]

It was suggested to extend `Collection` with a subscript like `a[safe: 0 ..< 
5]` which resembles the current subsequence subscript 
.
 Alternatively, we could bring collections even closer to ranges by extending 
them with the equivalent `.clamped(to:)` method:

let b = a.clamped(to: 0 ..< 5) // "safe" subsequence

— Pyry


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

Re: [swift-evolution] [Proposal] Safer half-open range operator

[Maximilian Hünenberger via swift-evolution]

Should this new operator form a new range? How can this range know about the 
array's indices?

A while ago there was a proposal (unfortunately it was not discussed enough) 
which introduced safe array indexing:

 array[safe: 3] // returns nil if index out of bounds

So another way to handle this issue would be to make another subscript like:

 array[truncate: -1...6]

Best regards
- Maximilian

> Am 12.04.2016 um 01:21 schrieb Luis Henrique B. Sousa via swift-evolution 
> :
> 
> The idea of having a new operator following the principles of overflow 
> operators looks great. Two distinct operators doing implicit and explicitly 
> might really be a good way to go; it would be concise and wouldn't look like 
> some magic happened behind the scenes. I'd like to hear more opinions about 
> it.
> 
> > what we'll have in case a[-1 &..< 5]? should this raise error or become [0 
> > ..< 3] ? I think, the latter.
> I agree here, I'd choose the latter.
> 
> From my perspective, the behaviour I'm proposing is what a considerable 
> number of users expect, especially if coming from other languages that follow 
> that path. Of course I'm not comparing languages here, but considering the 
> Swift principles of being a safer language, in my opinion we'd rather have a 
> partial slice than a crash in execution time (when the user is not totally 
> aware of it).
> 
> Many thanks for all your additions so far. It's really good to see that these 
> things are not set in stone yet.
> 
> - Luis
> 
>> On Apr 11, 2016 4:21 PM, "Vladimir.S via swift-evolution" 
>>  wrote:
>> +1 for the idea "in general". But I also think that explicit is better than 
>> implicit, especially if we deal with possible errors. Just like we work in 
>> Swift with integer overflow : '+' will generate run time error, but saying 
>> &+ we point Swift that we know what we do.
>> 
>> but.. what we'll have in case a[-1 &..< 5]? should this raise error or 
>> become [0 ..< 3] ? I think, the latter.
>> 
>>> On 11.04.2016 17:02, Haravikk via swift-evolution wrote:
>>> I like the idea in theory, but the question is; is it really safer to
>>> return a result that the developer may not have wanted, versus an error
>>> indicating that a mistake may have been made? I wonder if perhaps there
>>> could be an alternative, such as a variation of the operator like so:
>>> 
>>> let b = a [0 &..< 5]// Equivalent to let b = a[0 ..< min(5, a.endIndex)],
>>> becomes let b = a[0 ..< 3]
>>> 
>>> I’m just not sure that we can assume that an array index out of range error
>>> is okay without some kind of indication from the developer, as otherwise we
>>> could end up returning a partial slice, which could end up causing an error
>>> elsewhere where the size of the slice is assumed to be 5 but isn’t.
>>> 
 On 11 Apr 2016, at 13:23, Luis Henrique B. Sousa via swift-evolution
 > wrote:
 
 This proposal seeks to provide a safer ..< (aka half-open range operator)
 in order to avoid **Array index out of range** errors in execution time.
 
 Here is my first draft for this proposal:
 https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/-safer-half-open-range-operator.md
 
 In short, doing that in Swift causes a runtime error:
 
 leta =[1,2,3]
 letb =a[0..<5]
 print(b)
 
 > Error running code:
 > fatal error: Array index out of range
 
 The proposed solution is to slice the array returning all elements that
 are below the half-open operator, even though the number of elements is
 lesser than the ending of the half-open operator. So the example above
 would return [1,2,3].
 We can see this very behaviour in other languages, such as Python and
 Ruby as shown in the proposal draft.
 
 This would eliminate the need for verifications on the array size before
 slicing it -- and consequently runtime errors in cases when the
 programmer didn't.
 
 Viewing that it is my very first proposal, any feedback will be helpful.
 
 Thanks!
 
 Luis Henrique Borges
 @luishborges
 ___
 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
> 

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Haravikk via swift-evolution]

> On 13 Apr 2016, at 04:46, plx via swift-evolution  
> wrote:
> 
> Invalidation is hard and I wouldn’t want anything held up to try and find a 
> solution first.

Oh I agree, that was partly my point though; while this proposal may leave us 
with the "un-Swifty" issue of being unable to explicitly handle invalidation, 
it should be possible to solve that later, i.e- this proposal does’t make us 
any more vulnerable to that problem than we are now, but I definitely agree 
that we could do with some kind of invalidation mechanism in future that 
developers can actually implement or respond to. I guess I was more thinking 
out loud about whether the problem affects the proposal or not, but I don’t 
think that solving it will place any restrictions on the API as proposed, 
definitely deserves a proposal of its own once the new indexing system is in 
place though!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] mapValues

[Miguel Angel Quinones via swift-evolution]

I'm +1 for adding mapValues. Very useful functionality and trivial to 
implement. 

> > I.e. I suggest to implement and mapKeys() also. It could be also useful in 
> > some situations.
> `mapKeys` is much more dangerous, because you could end up mapping many 
> values into a single key. You kind of need to combine the values somehow. 
> Perhaps:
>  
> extension Dictionary {
> func mapValues(_ valueTransform: @noescape Value throws ->OutValue) rethrows 
> ->[Key: OutValue] { … }
>  
> func mapKeys(_ keyTransform: @noescape Key throws ->OutKey) rethrows 
> ->[OutKey: [Value]] { … }
>  
> // Possibly flatMap variants, too?
> }
>  
> extension Dictionary where Value: Sequence {
> func reduceValues(_ initial: OutValue, combine: @noescape (OutValue, 
> Value.Iterator.Element) throws ->OutValue) rethrows ->[Key: OutValue] {
> return mapValues { $0.reduce(initial, combine: combine) }
> }
> }
>  
> Which you would end up using like this:
>  
> let wordFrequencies: [String: Int] = …
> let firstLetterFrequencies: [Character: Int] = wordFrequencies.mapKeys { 
> $0.characters.first! }.reduceValues(0, combine: +)
>  
> --
> Brent Royal-Gordon
> Architechies
>  
>  
>  
>

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

Re: [swift-evolution] [Proposal] mapValues

[Brent Royal-Gordon via swift-evolution]

> I.e. I suggest to implement and mapKeys() also. It could be also useful in 
> some situations.

`mapKeys` is much more dangerous, because you could end up mapping many values 
into a single key. You kind of need to combine the values somehow. Perhaps:

extension Dictionary {
func mapValues(_ valueTransform: @noescape Value 
throws -> OutValue) rethrows -> [Key: OutValue] { … }

func mapKeys(_ keyTransform: @noescape Key 
throws -> OutKey) rethrows -> [OutKey: [Value]] { … }

// Possibly flatMap variants, too?
}

extension Dictionary where Value: Sequence {
func reduceValues(_ initial: OutValue, combine: 
@noescape (OutValue, Value.Iterator.Element) throws -> OutValue) rethrows -> 
[Key: OutValue] {
return mapValues { $0.reduce(initial, combine: combine) 
}
}
}

Which you would end up using like this:

let wordFrequencies: [String: Int] = …
let firstLetterFrequencies: [Character: Int] = wordFrequencies.mapKeys 
{ $0.characters.first! }.reduceValues(0, combine: +)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal] mapValues

[Vladimir.S via swift-evolution]

+1 for this. Highly useful method and imo should be implemented for Dictionary.

And what if we need to transform the key?
For ex. we have
var d = ["1" : "abc", "2" : "def"]
we could have such method:
d.mapKeys {k,v -> Int in Int(k)! }
to get:
[2: "abc", 1: "def"]

I.e. I suggest to implement and mapKeys() also. It could be also useful in 
some situations.


On 13.04.2016 9:41, Jonathan Hull via swift-evolution wrote:

I would really like to see something like the following added to the
standard library:

extensionDictionary{


func mapValues(transform:(Key,Value)->U)->[Key:U] {
var output:[Key:U] = [:]
for (k,v) in self {
 output[k] = transform(k,v)
 }
return output
 }


}

It comes up enough that I have had to add it to pretty much every one of my
projects.  I also don’t feel comfortable adding it to my frameworks, since
I figure a lot of people are also adding something like this to their
projects, and I don’t want to cause a conflict with their version.  Prime
candidate for the standard library.

I like calling it ‘mapValues' as opposed to providing an override for map,
since it makes the specific behavior more clear.  I would expect ‘map' to
possibly map the keys as well (though there are issues where the new keys
overlap).  I suppose you could just have a bunch of overrides for map if
the compiler becomes good enough at differentiating return types:
(Value)->(Value), (Key,Value)->Value, (Key, Value)->(Key,Value)

Thanks,
Jon


___
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] mapValues

[Brent Royal-Gordon via swift-evolution]

> I would really like to see something like the following added to the standard 
> library:
> 
> extension Dictionary {
> 
> func mapValues(transform:(Key,Value)->U)->[Key:U] {
> var output:[Key:U] = [:]
> for (k,v) in self {
> output[k] = transform(k,v)
> }
> return output
> }
> 
> }

+1 from me, and +78 from people on Stack Overflow: 


-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal] mapValues

[Dave via swift-evolution]

“map” already "maps the values” so I think something like “transform” might be 
a little clearer, if we don’t want to just overload “map”. Regardless of what 
it’s called, though, I’m +1 on the functionality.

- Dave Sweeris

> On Apr 13, 2016, at 1:41 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I would really like to see something like the following added to the standard 
> library:
> 
> extension Dictionary {
> 
> func mapValues(transform:(Key,Value)->U)->[Key:U] {
> var output:[Key:U] = [:]
> for (k,v) in self {
> output[k] = transform(k,v)
> }
> return output
> }
> 
> }
> 
> It comes up enough that I have had to add it to pretty much every one of my 
> projects.  I also don’t feel comfortable adding it to my frameworks, since I 
> figure a lot of people are also adding something like this to their projects, 
> and I don’t want to cause a conflict with their version.  Prime candidate for 
> the standard library.
> 
> I like calling it ‘mapValues' as opposed to providing an override for map, 
> since it makes the specific behavior more clear.  I would expect ‘map' to 
> possibly map the keys as well (though there are issues where the new keys 
> overlap).  I suppose you could just have a bunch of overrides for map if the 
> compiler becomes good enough at differentiating return types: 
> (Value)->(Value), (Key,Value)->Value, (Key, Value)->(Key,Value)
> 
> Thanks,
> Jon
> ___
> 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] How to eliminate 'optional' protocol requirements

[Dave via swift-evolution]

What about this? I’m unfamiliar with the details of objc-swift 
interoperability, so I’m not actually sure it could work this way, nor am I 
certain that I’m not just “rephrasing” something that’s already been suggested.
protocol SomeProtocol {
//Non-optional stuff goes here
}
extension SomeProtocol {
//Optional stuff goes here
func blah() {
//Default implementation goes here
}
}

protocol SomeSubProtocol : SomeProtocol {
//The same optional stuff goes here again
func blah()
}

func foo (x:T) {
if let x = x as? SomeSubProtocol {
x.blah() //Is custom implementation because we know x is 
SomeOtherProtocol
} else {
x.blah() //Is default implementation because we know it's not
}
...
}

(It seems like there ought to be a less repetitive way to do the branch. The 
problem is that any expression would necessarily have to evaluate to two 
different types, depending on whether T conforms to the sub protocol.)

Anyway, does that correctly model the relationship between optional 
requirements and their protocols? I’ve used optional protocol requirements just 
enough to use UIKit and such, but I find the whole self-contradictional 
"optional requirement” thing confusing enough that I’ve never really felt like 
I understand them. There’s a fair chance that I’m missing their point.

If that is the correct model, is there a way to automatically create all the 
objc “subprotocols" as they’re being imported into swift? If so, would it be 
beneficial to maybe “nest” the protocols to prevent UIKit from declaring 50 
million “top level” protocols?
protocol SomeProtocol {
protocol SomeOtherProtocol { // the " : SomeProtocol" part is implied
func blah() -> Int
}
//Non-optional stuff goes here
}
extension SomeProtocol {
//Optional stuff goes here
func blah() -> Int {
return 5
}
}
func blah (x:T) -> Int {
if let x = x as? SomeProtocol.SomeOtherProtocol {…}
}

- Dave Sweeris

> On Apr 13, 2016, at 12:47 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Apr 8, 2016, at 8:53 AM, Shawn Erickson > > wrote:
>> 
>> I want to reiterate that I have objective-c code, others have objc code, and 
>> the cocoa, etc. frameworks have code that depend on optional protocol for 
>> things like (but not limited to) delegates. This is of course obvious but 
>> what seems to get lost in the discussion is that you can't always replace 
>> the non-existence of an implementation of an optional protocol method with a 
>> default implementation.
>> 
>> I have code that probes a delegate when registered and based on the what 
>> subset of the optional protocol methods it handles configures its runtime 
>> state to optimize itself to that reality. For example it may avoid 
>> allocating and maintaining potentially complex state if one or more methods 
>> are not implemented by the delegate (since no one is interested in it). If 
>> we just blindly provide default  implementation for optional methods then 
>> this optimization couldn't take place.
>> 
>> I know others - including I believe Apple framework code - do similar 
>> optimizations based on what methods an object implements.
> 
> Just to be very clear (which I think my initial post wasn’t) my proposal does 
> *not* break this optimization when a Swift class is conforming to an @objc 
> protocol: even if a default is present, it won’t be visible to the 
> Objective-C runtime at all.
> 
> My proposal *does* make it significantly harder to implement a check for “did 
> the type implement this method?”, because one will effectively have to use 
> -respondsToSelector:. For Cocoa-defined delegates, that doesn’t matter at 
> all: apps generally implement requirements of delegates/data sources, but 
> almost never go through the protocol to use those methods/properties. It’s 
> the frameworks that do the calling, and of course they’re already using 
> -respondsToSelector: checks.
> 
> The main effect is in Swift code that uses @objc optionals and tests for the 
> absence of an implementation to perform some optimization. The tenor of the 
> previous thread seems to indicate that this probably isn’t common, because 
> there are probably better ways to model these cases in Swift—whether it’s 
> with multiple protocols or something that specifically describes the policy 
> (e.g., 
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/13347/focus=13480 
> ).
> 
> 
>> I think we should maintain the optional concept in support of bridging 
>> existing objc code into swift (confined to @objc)... unless a way to bridge 
>> things can be defined that avoids the loss of optimization potential I 
>> outlined above.
> 
> The direction I’m trying to go is not to have half of a feature—something 
> that seems like it should be general, but is tied to 

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Douglas Gregor via swift-evolution]

> On Apr 12, 2016, at 11:23 PM, David Hart via swift-evolution 
>  wrote:
> 
> I wouldn't mind driving the discussion and proposal, because I'd really like 
> to see a more complete generics system. Before I start, can David or Doug, or 
> someone else with a high-level view of the generics system tell me if this is 
> where to start or if there is another feature in the Complete Generics 
> manifesto which is more urgent first?

I think this is a fine feature to focus on. It’s useful, fits well in the 
system, and it’s scope is small enough that it’s achievable.

- Doug

> 
> David
> 
> On 13 Apr 2016, at 01:46, Jacob Bandes-Storch via swift-evolution 
> > wrote:
> 
>> I'm interested, but I'm by no means claiming I'll have enough time to drive 
>> any of the discussion/proposal/implementation. :-(
>> 
>> Jacob
>> 
>> On Tue, Apr 12, 2016 at 3:07 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> on Tue Apr 12 2016, Douglas Gregor > > wrote:
>> 
>> > On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution
>> > > wrote:
>> >
>> > Doug wrote this in the Completing Generics manifesto, under "Minor
>> > extensions":
>> >
>> > *Arbitrary requirements in protocols
>> >
>> > Currently, a new protocol can inherit from other protocols, 
>> > introduce
>> > new associated types, and add new conformance constraints to 
>> > associated
>> > types (by redeclaring an associated type from an inherited 
>> > protocol).
>> > However, one cannot express more general constraints. Building on 
>> > the
>> > example from “Recursive protocol constraints”, we really want the
>> > element type of a Sequence’s SubSequence to be the same as the 
>> > element
>> > type of the Sequence, e.g.,
>> >
>> > protocol Sequence {
>> > associatedtype Iterator : IteratorProtocol
>> > …
>> > associatedtype SubSequence : Sequence where 
>> > SubSequence.Iterator.Element
>> > == Iterator.Element
>> > }
>> >
>> > +1.
>> >
>> > To make it into Swift 3, would this feature require a proposal of its 
>> > own?
>> >
>> > Yes. Also, be wary that the syntax above potentially conflicts with the 
>> > syntax
>> > discussed as "moving the where clauses”:
>> >
>> > http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058 
>> > 
>> >
>> > How feasible would it be to implement on top of the current system?
>> >
>> > Definitely! The archetype builder would need to learn to check these extra 
>> > where
>> > clauses, and one would need to be sure that the constraint solver is 
>> > picking
>> > them up as well.
>> 
>> By the way, having this would enable us to massively simplify the
>> standard library, and potentially lots of user-written generic code,
>> too.  So I'm very excited that someone's interested!
>> 
>> --
>> 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

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

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Douglas Gregor via swift-evolution]

> On Apr 12, 2016, at 11:19 PM, David Hart  wrote:
> 
> Hi Doug,
> 
> I've read the discussion about moving the where clause to the right of 
> declarations (which I full-heartedly approve) but I don't see how it would 
> have any impact on the syntax of associated types requirements.

I think “arbitrary requirements in protocols” doesn’t necessarily require them 
to be attached to an associated type. For example, Collection might require 
that the SubSequence type itself be a Collection:

protocol Collection : Sequence {
  associatedtype SubSequence : Collection
} 

Why did we have to declare the SubSequence associated type again (since it’s 
already down in SubSequence) just to make it conform to Collection. In fact, 
why are we even allowed to declare a redundant associated type, which we know 
is defined in Sequence and will have to be the same? Seems to me that we just 
want a where clause to add the constraint, e.g.,

protocol Collection : Sequence {
  where SubSequence : Collection
} 

which of course would conflict with moving where clauses later, e.g.,

protocol Collection : Sequence {
  func foo() // is the following where clause part of foo() or part of 
Collection?
  where SubSequence : Collection
} 


- Doug


> 
> David
> 
> On 12 Apr 2016, at 19:07, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> 
>>> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution 
>>> > wrote:
>>> 
>>> Doug wrote this in the Completing Generics manifesto, under "Minor 
>>> extensions":
>>> 
>>> *Arbitrary requirements in protocols
>>>  
>>> Currently, a new protocol can inherit from other protocols, introduce new 
>>> associated types, and add new conformance constraints to associated types 
>>> (by redeclaring an associated type from an inherited protocol). However, 
>>> one cannot express more general constraints. Building on the example from 
>>> “Recursive protocol constraints”, we really want the element type of a 
>>> Sequence’s SubSequence to be the same as the element type of the Sequence, 
>>> e.g.,
>>>  
>>> protocol Sequence {
>>> associatedtype Iterator : IteratorProtocol
>>> …
>>> associatedtype SubSequence : Sequence where 
>>> SubSequence.Iterator.Element == Iterator.Element
>>> }
>>> 
>>> 
>>> +1.
>>> 
>>> To make it into Swift 3, would this feature require a proposal of its own?
>> 
>> Yes. Also, be wary that the syntax above potentially conflicts with the 
>> syntax discussed as "moving the where clauses”:
>> 
>>  
>> http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058 
>> 
>> 
>> 
>>> How feasible would it be to implement on top of the current system?
>> 
>> Definitely! The archetype builder would need to learn to check these extra 
>> where clauses, and one would need to be sure that the constraint solver is 
>> picking them up as well.
>> 
>>  - Doug
>> 
>> 
>> ___
>> 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] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

> On Apr 11, 2016, at 10:15 AM, Joe Groff  wrote:
> 
> 
>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> One could perhaps work around (a), (b), and (d) by allowing compound 
>> (function-like) names like tableView(_:viewFor:row:) for properties, and 
>> work around (c) by allowing a method to satisfy the requirement for a 
>> read-only property, but at this point you’ve invented more language hacks 
>> than the existing @objc-only optional requirements. So, I don’t think there 
>> is a solution here.
> 
> To me, compound names for closure properties and satisfying property 
> requirements with methods aren't hacks, they're missing features we ought to 
> support anyway. I strongly prefer implementing those over your proposed 
> solution.

I haven’t seen these come up in any discussion that wasn’t about mapping 
Objective-C optional requirements to something else in Swift. What other use 
cases are you envisioning?

>  It sounds to me like a lot of people using optional protocol requirements 
> *want* the locality of control flow visible in the caller, for optimization 
> or other purposes,

Most of the requests I see for this feature are of the form “this works for 
@objc protocols, so it should work everywhere,” and most of the push-back I’ve 
seen against removing ‘optional’ is a concern over interaction with Cocoa. I 
haven’t gotten the sense that optional requirements are considered to be the 
best design for any particular task in Swift.

> and your proposed solution makes this incredibly obscure and magical.


That’s fair. The mechanism I’m talking about *is* a bit hard to explain—we 
would need to rely on the diagnostic for cases where one tries to call a method 
that is caller-defaulted from Swift code, e.g.,

error: method ‘foo(bar:wibble:)’ may not be implemented by the adopting 
class; add a default implementation via an extension to protocol ‘Foo'

This would only affect optional requirements of protocols imported from 
Objective-C. My hypothesis is that those just aren’t used in Swift app code.

- Doug

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

Re: [swift-evolution] Crypto routines as part of the core library

[Vladimir.S via swift-evolution]

I believe we already have a number of community-developed crypto libs for 
Swift, the problem is not in the lib itself. The problem, as I see it, is 
in one _choosen_ (and so, well-tested and supported by main team) that will 
be brought into Swift. Yes, also don't think Swift team should create such 
a new crypto lib from zero, some well-known lib imo will be better solution.
The question is - are there any plans in Swift team to provide "built-in" 
crypto libs for Swift 3.0+ ?


On 13.04.2016 9:06, Brent Royal-Gordon via swift-evolution wrote:

It would seem to me that common crypto routines should become part of the core 
Swift libraries without having to rely on unknown third party libraries or 
bridging into the C based CommonCrypto lib.


This seems like a great candidate for a library that could be developed in the 
community and then possibly brought into Corelibs in a future version, but I 
strongly suspect it'll be considered out of scope for Swift 3.


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

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[David Hart via swift-evolution]

I wouldn't mind driving the discussion and proposal, because I'd really like to 
see a more complete generics system. Before I start, can David or Doug, or 
someone else with a high-level view of the generics system tell me if this is 
where to start or if there is another feature in the Complete Generics 
manifesto which is more urgent first?

David

> On 13 Apr 2016, at 01:46, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> I'm interested, but I'm by no means claiming I'll have enough time to drive 
> any of the discussion/proposal/implementation. :-(
> 
> Jacob
> 
>> On Tue, Apr 12, 2016 at 3:07 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Tue Apr 12 2016, Douglas Gregor  wrote:
>> 
>> > On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution
>> >  wrote:
>> >
>> > Doug wrote this in the Completing Generics manifesto, under "Minor
>> > extensions":
>> >
>> > *Arbitrary requirements in protocols
>> >
>> > Currently, a new protocol can inherit from other protocols, 
>> > introduce
>> > new associated types, and add new conformance constraints to 
>> > associated
>> > types (by redeclaring an associated type from an inherited 
>> > protocol).
>> > However, one cannot express more general constraints. Building on 
>> > the
>> > example from “Recursive protocol constraints”, we really want the
>> > element type of a Sequence’s SubSequence to be the same as the 
>> > element
>> > type of the Sequence, e.g.,
>> >
>> > protocol Sequence {
>> > associatedtype Iterator : IteratorProtocol
>> > …
>> > associatedtype SubSequence : Sequence where 
>> > SubSequence.Iterator.Element
>> > == Iterator.Element
>> > }
>> >
>> > +1.
>> >
>> > To make it into Swift 3, would this feature require a proposal of its 
>> > own?
>> >
>> > Yes. Also, be wary that the syntax above potentially conflicts with the 
>> > syntax
>> > discussed as "moving the where clauses”:
>> >
>> > http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058
>> >
>> > How feasible would it be to implement on top of the current system?
>> >
>> > Definitely! The archetype builder would need to learn to check these extra 
>> > where
>> > clauses, and one would need to be sure that the constraint solver is 
>> > picking
>> > them up as well.
>> 
>> By the way, having this would enable us to massively simplify the
>> standard library, and potentially lots of user-written generic code,
>> too.  So I'm very excited that someone's interested!
>> 
>> --
>> 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] [Completing Generics] Arbitrary requirements in protocols

[David Hart via swift-evolution]

Hi Doug,

I've read the discussion about moving the where clause to the right of 
declarations (which I full-heartedly approve) but I don't see how it would have 
any impact on the syntax of associated types requirements.

David

> On 12 Apr 2016, at 19:07, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>>> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution 
>>>  wrote:
>>> 
>>> Doug wrote this in the Completing Generics manifesto, under "Minor 
>>> extensions":
>>> 
>> 
>>> *Arbitrary requirements in protocols
>>>  
>>> Currently, a new protocol can inherit from other protocols, introduce new 
>>> associated types, and add new conformance constraints to associated types 
>>> (by redeclaring an associated type from an inherited protocol). However, 
>>> one cannot express more general constraints. Building on the example from 
>>> “Recursive protocol constraints”, we really want the element type of a 
>>> Sequence’s SubSequence to be the same as the element type of the Sequence, 
>>> e.g.,
>>>  
>>> protocol Sequence {
>>> associatedtype Iterator : IteratorProtocol
>>> …
>>> associatedtype SubSequence : Sequence where 
>>> SubSequence.Iterator.Element == Iterator.Element
>>> }
>> 
>> 
>> +1.
>> 
>> To make it into Swift 3, would this feature require a proposal of its own?
> 
> Yes. Also, be wary that the syntax above potentially conflicts with the 
> syntax discussed as "moving the where clauses”:
> 
>   
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058
> 
> 
>> How feasible would it be to implement on top of the current system?
> 
> Definitely! The archetype builder would need to learn to check these extra 
> where clauses, and one would need to be sure that the constraint solver is 
> picking them up as well.
> 
>   - Doug
> 
> 
> ___
> 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] Crypto routines as part of the core library

[Brent Royal-Gordon via swift-evolution]

> It would seem to me that common crypto routines should become part of the 
> core Swift libraries without having to rely on unknown third party libraries 
> or bridging into the C based CommonCrypto lib. 

This seems like a great candidate for a library that could be developed in the 
community and then possibly brought into Corelibs in a future version, but I 
strongly suspect it'll be considered out of scope for Swift 3.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Crypto routines as part of the core library

[Vladimir.S via swift-evolution]

+1, totally agree with this. Сrypto routines are very important part of 
code (when they are used in application). So I believe we need standard, 
well-tested and supported by Swift team crypto libraries we can rely on.


It is ok to rely on 3rd party libraries in other areas, but IMO it is 
crucial to have "built-in" crypto functions in standard library(s).
Probably not "full set" of algorithms, features, etc but believe that 
standard base algorithms/features (like MD5/SHA/AES/RSA) must be available.


Is there some information regarding crypto functions for Swift 3.0?

On 13.04.2016 6:45, Travis Beech via swift-evolution wrote:

It would seem to me that common crypto routines should become part of the core 
Swift libraries without having to rely on unknown third party libraries or 
bridging into the C based CommonCrypto lib.

Just some things off the top of my head that we should be able to do easily in 
pure Swift is AES encryption, digests such as HMAC SHA1, dealing with 
certificates and keys, support for other encryption algorithms such as RSA.

Am I completely off base for wanting this? These features exist in other 
languages such as Java and C#.

Thank you,

Travis Beech  |  Principal Developer  |  Unwired Revolution  |  c: 1 (209) 
535-5357
Optimizing Operations for Mobile and Distributed Systems
___
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