[swift-evolution] Can functions/methods be overloaded on mutability of parameters?

[Daryle Walker via swift-evolution]

Can I make two overloads such that one can take an argument from a “let”-mode 
object or a regular function parameter and return an UnsafePointer and then 
have the other take a “var”-mode object or inout function parameter and return 
an UnsafeMutablePointer? I think this can be done in C++.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Pitch: String Index Overhaul

[Dave Abrahams via swift-evolution]

on Fri Jun 02 2017, Brent Royal-Gordon  wrote:

>> On May 27, 2017, at 10:40 AM, Dave Abrahams via swift-evolution
>  wrote:
>> 
>> A property and an intializer will be added to `String.Index`, exposing
>> the offset of the index in code units (currently only UTF-16) from the
>> beginning of the string:
>> 
>> ```swift
>> let n: Int = html.endIndex.encodedOffset
>> let end = String.Index(encodedOffset: n)
>> assert(end == String.endIndex)
>> ```
>
> Do you intend to allow users to serialize an `encodedOffset` and
> deserialize it later, perhaps in a later version of Swift, to
> represent the same position? If so, I'm not sure how you intend to
> maintain compatibility once the "currently only UTF-16" notation is no
> longer true.

Strings will offer access to their underlying code units, and can be
serialized and deserialized however they are represented.  A String
stored as UTF-8 will be serialized and deserialized as UTF-8, so
encodedOffsets will maintain their meanings.

Cheers,
-- 
-Dave

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

Re: [swift-evolution] Pitch: String Index Overhaul

[Brent Royal-Gordon via swift-evolution]

> On May 27, 2017, at 10:40 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> A property and an intializer will be added to `String.Index`, exposing
> the offset of the index in code units (currently only UTF-16) from the
> beginning of the string:
> 
> ```swift
> let n: Int = html.endIndex.encodedOffset
> let end = String.Index(encodedOffset: n)
> assert(end == String.endIndex)
> ```


Do you intend to allow users to serialize an `encodedOffset` and deserialize it 
later, perhaps in a later version of Swift, to represent the same position? If 
so, I'm not sure how you intend to maintain compatibility once the "currently 
only UTF-16" notation is no longer true.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[Andrew Trick via swift-evolution]

> On Jun 2, 2017, at 2:20 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution 
>> > wrote:
>> 
>> Static-Sized Arrays
> 
> My preference would still be to build this from four separate features:
> 
> 1. Magic tuple conformances: We already want to be able to automatically 
> conform tuples to protocols like Equatable, Hashable, and Comparable. These 
> can all be compiler magic; they don't have to be definable in userspace.
> 
> 2. Conform tuples to Collection: The Element type should be the most specific 
> common supertype of the tuple's elements. If all the elements are the same 
> type, it would be that type. The Index and IndexDistance types should be Int.
> 
> 3. Conform same-type tuples to MutableCollection: If all elements are the 
> same type, you can also modify the values. (If their types vary in any way, 
> however, it would not be safe to allow mutations, since you could assign the 
> wrong type to an element.)
> 
> 3. Add sugar for a tuple of N identical elements: Probably something like `4 
> * Int`, but opinions can vary.
> 
> This solution avoids adding another structural type to the language or 
> introducing non-type generic parameters. It also addresses other needs: 1 and 
> 2 are desirable features in their own right which address other use cases in 
> addition to this one. And it's nicely incremental, which is always a plus.
> 
> -- 
> Brent Royal-Gordon
> Architechies

+1. Sounds great to me as long as the type system can handle it cleanly.
-Andy
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Tommaso Piazza via swift-evolution]

Thanks, added. 

On Friday, June 2, 2017 1:18 PM, Vladimir.S  wrote:
 

 On 02.06.2017 2:34, Tommaso Piazza wrote:
> Is the version you suggest to add to my list for the Swift syntax currently 
> valid as 
> of SE-0110 in Swift 4?

Yes, just checked on latest dev snapshot of Swift 4.

> 
> 
> On Thursday, June 1, 2017 9:32 PM, Vladimir.S  wrote:
> 
> 
> On 01.06.2017 19:31, Tommaso Piazza wrote:
>  > Dear all,
>  >
>  > I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it 
>stands in
>  > comparison with other languages
>  >
>  > https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935
>  >
> 
> Thank you! Very useful information. And also I really like the opinion of
> @AliSoftware in comments for this article.
> 
> I'd suggest to add this variant to Swift section in your article:
> 
> let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {
>      (arg: (name: String, age: Int)) in arg.age >= 18 }
> 
> (I believe it is better that 2 others Swift variants.)
> 
> It seems for me that we need to allow some special syntax for *explicit* tuple
> destructuring in closures to make all happy.
> 
> FWIW These suggestions are my favorite:
> 
> 1. Just allow type inference for tuple's destructured variables in this 
> position:
> 
> .filter { (arg: (name, age)) in arg.age >= 18 }
> 
> 
> 2. (1) + allow underscore for tuple argument name:
> 
> .filter { (_: (name, age)) in age >= 18 }
> 
> 
> 3. (2) + allow to omit parenthesis (probably only in case of just one tuple 
> argument)
> 
> .filter { _: (name, age) in age >= 18 }
> 
> 
> 4. Use pattern matching syntax:
> 
> .filter { case let (name, age) in age >= 18 }
> 
> (looks similar as allowed today: if case let (name, age) = x { print(name, 
> age) }  )
> 
> 
> 5. Use two pairs of parenthesis :
> 
> .filter { ((name, age)) in age >= 18 }
> 
> Btw, about the 5th variant. If took what is allowed today:
> .filter { (arg: (name: String, age: Int)) in arg.age >= 18 }
> , and allow type inference for tuple part arguments, we'll have this:
> .filter { (arg: (name, age)) in arg.age >= 18 }
> , and if additionally allow skipping of tuple argument declaration we'll have:
> .filter { ((name, age)) in arg.age >= 18 }
> I.e. two pairs for parenthesis for tuple destructuring, and such syntax is 
> similar to
> the type this closure should have : ((String, Int)) -> Bool
> 
> 
>  >
>  >
>  >
>  > On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution
>  > > wrote:
>  >
>  >
>  > On 01.06.2017 0:42, John McCall wrote:
>  >  >> On May 31, 2017, at 2:02 PM, Stephen Celis  
>  > >> wrote:
>  >  >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
>  >  >>>  
> >> wrote:
>  >  >>>
>  >  >>> Yes, I agree.  We need to add back tuple destructuring in closure 
>parameter
>  >  >>> lists because this is a serious usability regression.  If we're 
>reluctant to
>  >  >>> just "do the right thing" to handle the ambiguity of (a,b), we should 
>at least
>  >  >>> allow it via unambiguous syntax like ((a,b)).  I do think that we 
>should just
>  >  >>> "do the right thing", however, with my biggest concern being whether 
>there's
>  >  >>> any reasonable way to achieve that in 4.0.
>  >  >>
>  >  >> Closure parameter lists are unfortunately only half of the equation 
>here. This
>  >  >> change also regresses the usability of point-free expression.
>  >  >
>  >  > The consequences for point-free style were expected and cannot really be
>  >  > eliminated without substantially weakening SE-0110.  Closure 
>convenience seems to
>  >  > me to be a much more serious regression.
>  >
>  > John, do you also want to say "and without weakening SE-0066"? Because, if 
>I
>  > understand correctly, in this case:
>  >
>  >    func add(_ x: Int, _ y: Int) -> Int {
>  >      return x + y
>  >    }
>  >
>  >    zip([1, 2, 3], [4, 5, 6]).map(add)
>  >
>  > .. we have a clear function type mismatch situation, when map() expects 
>function of
>  > type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? 
>So probably
>  > the additional 'reason' of the 'problem' in this case is SE-0066, no?
>  > Or I don't understand the SE-0066 correctly..
>  > Do we want to allow implicit conversions between function type 
>((Int,Int))->Int and
>  > (Int,Int)->Int?
>  >
>  > Quote from SE-0066:
>  > ---
>  > (Int, Int) -> Int    // function from Int and Int to Int
>  > ((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
>  > ---
>  >
>  > During this discussion I see a wish of some group of developers to just 
>return back
>  > tuple splatting for function/closure arguments, so they can 

Re: [swift-evolution] Sparse (fixed-size) array literal syntax

[John McCall via swift-evolution]

> On Jun 1, 2017, at 10:49 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or linear 
> arrays, but isn’t so great later on when we add fixed-size arrays and the 
> defined (non-zero) elements are sparse and/or the array is multi-dimensional 
> (not nested). In these cases I’m thinking of leading each element with its 
> coordinate:
> 
> … 6: a, …  // complete value, linear array
> … (1, 2): b, …  // complete value, multi-dimensional array
> … (let x, let y) where y % 2 == 0: c * y + x, …  // pattern of qualifying 
> coordinates
> … default: d, …  // when no other initializer covers an element (Use “_” 
> instead?)
> 
> A complete coordinate beats a pattern, which beats a default. The issue I see 
> here is that I’m using a colon as a separator between the coordinate 
> expression and the value expression. Would that interfere with dictionary 
> literal syntax? Would it help the we’ll most likely have to demand that the 
> object receiving the literal has to have its type specified (with whatever 
> syntax we agree on), as either a declared object with a type annotation or a 
> function parameter (for a function either without overload or with the 
> variant used otherwise made clear)?

"Literals" like this are obviously complicated to the point that you would be 
much better off just using an initializer that takes a function to construct 
each element.  There's no point in reinventing switches in the array-literal 
syntax.

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[Dave Abrahams via swift-evolution]

on Fri Jun 02 2017, Brent Royal-Gordon  wrote:

>> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution
>>  wrote:
>> 
>> Static-Sized Arrays
>
> My preference would still be to build this from four separate features:
>
> 1. Magic tuple conformances: We already want to be able to
> automatically conform tuples to protocols like Equatable, Hashable,
> and Comparable. These can all be compiler magic; they don't have to be
> definable in userspace.
>
> 2. Conform tuples to Collection: The Element type should be the most
> specific common supertype of the tuple's elements. If all the elements
> are the same type, it would be that type. The Index and IndexDistance
> types should be Int.
>
> 3. Conform same-type tuples to MutableCollection: If all elements are
> the same type, you can also modify the values. (If their types vary in
> any way, however, it would not be safe to allow mutations, since you
> could assign the wrong type to an element.)
>
> 3. Add sugar for a tuple of N identical elements: Probably something
> like `4 * Int`, but opinions can vary.

I think any complete solution depends on at least two more things:

1. adding the ability to get an UnsafePointer to an immutable instance
   of value type

2. support for leaving some of the elements uninitialized, or
   alternatively, a variation of this type that is RangeReplaceable but
   also bounded in capacity.

-- 
-Dave

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

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

John and others, who are involved into this thread.
I'd suggest to clarify the current(Swift4) situation with function/closure type 
before we make any other decision and before continue to discuss the subject.
(sorry for long email, but I feel the problem with SE-0110 is wider than just "let's 
just drop it")


Please review this code and its result 
(swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-01-a-osx) :


func fooParam(_ x: Int, _ y: Int){}
func fooTuple(_ x: (Int, Int)) {}

print("type of fooParam is", type(of:fooParam))
// type of fooParam is (Int, Int) -> ()

print("type of fooTuple is", type(of:fooTuple))
// type of fooTuple is (Int, Int) -> ()

print("type of fooParam == type of fooTuple ?", type(of: fooParam) == type(of: 
fooTuple))

// true

if fooParam is (Int,Int)->() { print("fooParam is (Int,Int)->()") }
// fooParam is (Int,Int)->()

if fooParam is ((Int,Int))->() { print("fooParam is ((Int,Int))->()") }
// fooParam is ((Int,Int))->()

if fooTuple is (Int,Int)->() { print("fooTuple is (Int,Int)->()") }
// fooTuple is (Int,Int)->()

if fooTuple is ((Int,Int))->() { print("fooTuple is ((Int,Int))->()") }
// fooTuple is ((Int,Int))->()


var closureParam = { (x: Int, y: Int) in  }
var closureTuple = { (x: (Int, Int)) in  }

print("type of closureParam is", type(of:closureParam))
// type of closureParam is (Int, Int) -> ()

print("type of closureTuple is", type(of:closureTuple))
// type of closureTuple is (Int, Int) -> ()

if closureParam is (Int,Int)->() { print("closureParam is (Int,Int)->()") }
// closureParam is (Int,Int)->()

if closureParam is ((Int,Int))->() { print("closureParam is ((Int,Int))->()") }
// closureParam is ((Int,Int))->()

if closureTuple is (Int,Int)->() { print("closureTuple is (Int,Int)->()") }
// closureTuple is (Int,Int)->()

if closureTuple is ((Int,Int))->() { print("closureTuple is ((Int,Int))->()") }
// closureTuple is ((Int,Int))->()


func barParams(_ callback: (Int,Int)->()) { callback(1,2) }

//barParams(fooTuple)
//error: cannot convert value of type '((Int, Int)) -> ()' to expected argument type 
'(Int, Int) -> ()'


//barParams(closureTuple)
//error: cannot convert value of type '((Int, Int)) -> ()' to expected argument type 
'(Int, Int) -> ()'


func barTuple(_ callback: ((Int,Int))->()) { let tuple = (1,2); callback(tuple) 
}

//barTuple(fooParam)
//error: nested tuple parameter '(Int, Int)' of function '(((Int, Int)) -> ()) -> ()' 
does not support destructuring


//barTuple(closureParam)
//error: cannot convert value of type '(Int, Int) -> ()' to expected argument type 
'((Int, Int)) -> ()'



So, what is the type of fooParam/fooTuple/closureParam/closureTuple ?
Why the type is different in different situations?
Should we have strong and unambiguous type for functions/closures and probably *then* 
allow implicit conversion like "(Int,Int)->() can be used when ((Int,Int))->() is 
required and vise-versa"?


We have all this inconsistency with function/closure types from Swift 2, and this 
should be actually fixed in Swift 3, but still we are going to keep that in Swift 4.


Personally, I'm not against tuple deconstructing in closures and even think we can 
just have allowed implicit conversion between func/closure with single tuple argument 
and a list of arguments. But, I do believe we need consistent state in this area, 
strong types and clear rules. Because of this, if we have no time to implement good 
solution/workaround for Swift 4, I believe it is better to keep/fully implement 
SE-0110 and then provide solution for tuple destructuring. Otherwise we are going to 
have all these mess with func/closure types for very long time after Swift 4. Or we 
can try to implement a good workaround before release.


In current Swift 4 we are allowed for this:
.filter {(arg: (name: String, age: Int)) in arg.age >= 18 }

Is it really no way(before Swift 4 is released) to allow type inference for 'name' 
and 'age'? I believe this could be a good *workaround*, totally in Swift way(just 
like you can omit types for arguments in closure, or can specify them), this will 
keep the existed syntax for closure arguments and this will not prevent us from 
suggesting best solution after the Swift 4 release. And IMO this is acceptable 
compromise between loosing tuple deconstruction and keep the mess with 
function/closure type:

.filter {(arg: (name, age)) in arg.age >= 18 }

Or, as I said, just allow implicit conversion between function/closure types taking 
one tuple argument and a list of arguments. But still .filter should expect exactly 
((Int,String))->()  but it is allowed to send (Int,String)->() to it. All is strongly 
typed, but with magic "conversion".


I still believe that SE-0066 was the proposal that answered all these questions and 
said that (Int,Int)->() and ((Int,Int))->() are two different types. SE-0110 just 
clarified that the same rule should be applied to closures.
Until we started to discuss revisiting of SE-0110 I was under strong impression that 

Re: [swift-evolution] Yet another fixed-size array spitball session

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 2, 2017, at 7:33 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> On Fri, Jun 2, 2017 at 04:28 Brent Royal-Gordon via swift-evolution 
>  wrote:
>>> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution 
>>>  wrote:
>>> 
>>> Static-Sized Arrays
>> 
>> My preference would still be to build this from four separate features:
>> 
>> 1. Magic tuple conformances: We already want to be able to automatically 
>> conform tuples to protocols like Equatable, Hashable, and Comparable. These 
>> can all be compiler magic; they don't have to be definable in userspace.
>> 
>> 2. Conform tuples to Collection: The Element type should be the most 
>> specific common supertype of the tuple's elements. If all the elements are 
>> the same type, it would be that type. The Index and IndexDistance types 
>> should be Int.
>> 
>> 3. Conform same-type tuples to MutableCollection: If all elements are the 
>> same type, you can also modify the values. (If their types vary in any way, 
>> however, it would not be safe to allow mutations, since you could assign the 
>> wrong type to an element.)
>> 
>> 3. Add sugar for a tuple of N identical elements: Probably something like `4 
>> * Int`, but opinions can vary.
>> 
>> This solution avoids adding another structural type to the language or 
>> introducing non-type generic parameters. It also addresses other needs: 1 
>> and 2 are desirable features in their own right which address other use 
>> cases in addition to this one. And it's nicely incremental, which is always 
>> a plus.
> 
> Exactly this. The whole conversation is wildly out of scope and the critical 
> technical details about implementation of the feature is either missing or 
> inaccurate, but I'll chime in for future reference to say that this 
> particular color of the shed is, in my view, the most congruent with Swift's 
> direction.

+1

> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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] Yet another fixed-size array spitball session

[Xiaodi Wu via swift-evolution]

On Fri, Jun 2, 2017 at 04:28 Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Static-Sized Arrays
>
> My preference would still be to build this from four separate features:
>
> 1. Magic tuple conformances: We already want to be able to automatically
> conform tuples to protocols like Equatable, Hashable, and Comparable. These
> can all be compiler magic; they don't have to be definable in userspace.
>
> 2. Conform tuples to Collection: The Element type should be the most
> specific common supertype of the tuple's elements. If all the elements are
> the same type, it would be that type. The Index and IndexDistance types
> should be Int.
>
> 3. Conform same-type tuples to MutableCollection: If all elements are the
> same type, you can also modify the values. (If their types vary in any way,
> however, it would not be safe to allow mutations, since you could assign
> the wrong type to an element.)
>
> 3. Add sugar for a tuple of N identical elements: Probably something like
> `4 * Int`, but opinions can vary.
>
> This solution avoids adding another structural type to the language or
> introducing non-type generic parameters. It also addresses other needs: 1
> and 2 are desirable features in their own right which address other use
> cases in addition to this one. And it's nicely incremental, which is always
> a plus.
>

Exactly this. The whole conversation is wildly out of scope and the
critical technical details about implementation of the feature is either
missing or inaccurate, but I'll chime in for future reference to say that
this particular color of the shed is, in my view, the most congruent with
Swift's direction.

>

> --
> Brent Royal-Gordon
> Architechies
>
> ___
> 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] Self's nominal restriction denies significant feature patterns

[Gwendal Roué via swift-evolution]

The key is to implement methods that deal with Self as protocol extensions. Not 
*in* the protocol itself:

// YES
protocol DAOProtocol {
init()
}

extension DAOProtocol {
static func retOne() -> Self {return self.init()}
static func retMany() -> Array { return [] }
static func retTuple() -> (Self, Int) { return (self.init(), 0) }
}

// NO
// protocol DAOProtocol {
// init()
// static func retOne() -> Self
// static func retMany() -> Array
// static func retTuple() -> (Self, Int)
// }

class Selfie : DAOProtocol{
required init() {}
}

Selfie.retOne()
Selfie.retMany()
Selfie.retTuple()

Beware: methods declared in protocol extensions *can not be customized* by 
adopting types. Only methods declared in the protocol itself can, and become 
customization points. This is an important constraint to think about when you 
design your protocols. Again, GRDB can be of great help for you: it has been 
working well for almost two years now.

Gwendal


> Le 2 juin 2017 à 12:10, Zaid Daghestani  a écrit :
> 
> *edit*
> Actual protocol implementation:
> 
> protocol Selfie {
> init()
> }
> extension Selfie {
> static func retOne() -> Self {return self.init()}
> static func retMany() -> Array { return [] }
> static func retTuple() -> (Self, Int) { return (self.init(), 0) }
> }
> 
> 
>> On Jun 2, 2017, at 3:08 AM, Zaid Daghestani > > wrote:
>> 
>> Wow, you’re right. Look like this is a bug? The issue shows up in class 
>> definitions, not protocol definitions.   
>> 
>> This works:
>> 
>> protocol Selfie {
>> static func retOne() -> Self
>> static func retMany() -> Array
>> static func retTuple() -> (Self, Int)
>> }
>> 
>> This doesn’t work:
>> 
>> class Selfie {
>> required init() {}
>> // Compiles
>> static func retOne() -> Self {return self.init()}
>> // Doesn't Compile
>> static func retMany() -> Array { return [] }
>> // Doesn't Compile
>> static func retTuple() -> (Self, Int) { return (self.init(), 0) }
>> 
>> }
>> 
>> So Self in non-nominal types with class methods end up with the compiler 
>> error:
>> 
>> Error: 'Self' is only available in a protocol or as the result of a method 
>> in a class; did you mean ’Selfie’?
>> 
>> Can we get confirmation from anyone?
>> 
>> 
>> 
>>> On Jun 2, 2017, at 2:39 AM, Gwendal Roué >> > wrote:
>>> 
>>> Hello Zaid,
>>> 
>>> I don't know what prevents you from implementing your DAOs.
>>> 
>>> For an example of a library that uses them extensively, see 
>>> http://github.com/groue/GRDB.swift: 
>>> 
>>> struct PointOfInterest {
>>> var id: Int64?
>>> var title: String?
>>> var favorite: Bool
>>> var coordinate: CLLocationCoordinate2D
>>> }
>>> 
>>> // (snip) adopt protocols that turn PointOfInterest in a "record"
>>> 
>>> // Fetch from SQL
>>> let pois = try PointOfInterest.fetchAll(db, "SELECT * FROM 
>>> pointOfInterests") // [PointOfInterest]
>>> 
>>> // Fetch without SQL
>>> let title = Column("title")
>>> let favorite = Column("favorite")
>>> let poi1 = try PointOfInterest.fetchOne(db, key: 1)   
>>> // PointOfInterest?
>>> let pois = try PointOfInterest.fetchOne(db, keys: [1, 2, 3])  
>>> // [PointOfInterest]
>>> let paris = try PointOfInterest.filter(title == "Paris").fetchOne(db) 
>>> // PointOfInterest?
>>> let favoritePois = try PointOfInterest
>>> // [PointOfInterest]
>>> .filter(favorite)
>>> .order(title)
>>> .fetchAll(db)
>>> 
>>> // Insert, update, delete
>>> var berlin = PointOfInterest(
>>> id: nil,
>>> title: "Berlin",
>>> favorite: false,
>>> coordinate: CLLocationCoordinate2DMake(52.52437, 13.41053))
>>> try berlin.insert(db)
>>> berlin.id // some value
>>> berlin.favorite = true
>>> try berlin.update(db)
>>> try berlin.delete(db)
>>> 
>>> GRDB "records" work pretty well with structs, but also class hierarchies, 
>>> without any caveat.
>>> 
>>> Can you explain a little more your issue ?
>>> 
>>> Gwendal Roué
>>> 
>>> 
 Le 2 juin 2017 à 11:18, Zaid Daghestani via swift-evolution 
 > a écrit :
 
 Greetings Swift Community,
 
 Today I’m throwing out a pitch on freeing the shackles on Self. Self is a 
 potentially significant tool that I am itching to implement in my patterns 
 to make my code more concise, clear and intuitive.
 
 Self, by far, is cherished by Data Models and ORM's, and particularly DAO 
  s (Ref. 1 for examples). There are a 
 

Re: [swift-evolution] Revisiting SE-0110

[Vladimir.S via swift-evolution]

On 02.06.2017 2:34, Tommaso Piazza wrote:
Is the version you suggest to add to my list for the Swift syntax currently valid as 
of SE-0110 in Swift 4?


Yes, just checked on latest dev snapshot of Swift 4.




On Thursday, June 1, 2017 9:32 PM, Vladimir.S  wrote:


On 01.06.2017 19:31, Tommaso Piazza wrote:
 > Dear all,
 >
 > I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it 
stands in
 > comparison with other languages
 >
 > https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935
 >

Thank you! Very useful information. And also I really like the opinion of
@AliSoftware in comments for this article.

I'd suggest to add this variant to Swift section in your article:

let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {
 (arg: (name: String, age: Int)) in arg.age >= 18 }

(I believe it is better that 2 others Swift variants.)

It seems for me that we need to allow some special syntax for *explicit* tuple
destructuring in closures to make all happy.

FWIW These suggestions are my favorite:

1. Just allow type inference for tuple's destructured variables in this 
position:

.filter { (arg: (name, age)) in arg.age >= 18 }


2. (1) + allow underscore for tuple argument name:

.filter { (_: (name, age)) in age >= 18 }


3. (2) + allow to omit parenthesis (probably only in case of just one tuple 
argument)

.filter { _: (name, age) in age >= 18 }


4. Use pattern matching syntax:

.filter { case let (name, age) in age >= 18 }

(looks similar as allowed today: if case let (name, age) = x { print(name, age) 
}  )


5. Use two pairs of parenthesis :

.filter { ((name, age)) in age >= 18 }

Btw, about the 5th variant. If took what is allowed today:
.filter { (arg: (name: String, age: Int)) in arg.age >= 18 }
, and allow type inference for tuple part arguments, we'll have this:
.filter { (arg: (name, age)) in arg.age >= 18 }
, and if additionally allow skipping of tuple argument declaration we'll have:
.filter { ((name, age)) in arg.age >= 18 }
I.e. two pairs for parenthesis for tuple destructuring, and such syntax is 
similar to
the type this closure should have : ((String, Int)) -> Bool


 >
 >
 >
 > On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution
 > > wrote:
 >
 >
 > On 01.06.2017 0:42, John McCall wrote:
 >  >> On May 31, 2017, at 2:02 PM, Stephen Celis 

 > >> wrote:
 >  >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
 >  >>>  
>> wrote:

 >  >>>
 >  >>> Yes, I agree.  We need to add back tuple destructuring in closure 
parameter
 >  >>> lists because this is a serious usability regression.  If we're 
reluctant to
 >  >>> just "do the right thing" to handle the ambiguity of (a,b), we should 
at least
 >  >>> allow it via unambiguous syntax like ((a,b)).  I do think that we 
should just
 >  >>> "do the right thing", however, with my biggest concern being whether 
there's
 >  >>> any reasonable way to achieve that in 4.0.
 >  >>
 >  >> Closure parameter lists are unfortunately only half of the equation 
here. This
 >  >> change also regresses the usability of point-free expression.
 >  >
 >  > The consequences for point-free style were expected and cannot really be
 >  > eliminated without substantially weakening SE-0110.  Closure convenience 
seems to
 >  > me to be a much more serious regression.
 >
 > John, do you also want to say "and without weakening SE-0066"? Because, if I
 > understand correctly, in this case:
 >
 >func add(_ x: Int, _ y: Int) -> Int {
 >  return x + y
 >}
 >
 >zip([1, 2, 3], [4, 5, 6]).map(add)
 >
 > .. we have a clear function type mismatch situation, when map() expects 
function of
 > type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? So 
probably
 > the additional 'reason' of the 'problem' in this case is SE-0066, no?
 > Or I don't understand the SE-0066 correctly..
 > Do we want to allow implicit conversions between function type 
((Int,Int))->Int and
 > (Int,Int)->Int?
 >
 > Quote from SE-0066:
 > ---
 > (Int, Int) -> Int// function from Int and Int to Int
 > ((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
 > ---
 >
 > During this discussion I see a wish of some group of developers to just 
return back
 > tuple splatting for function/closure arguments, so they can freely send 
tuple to
 > function/closure accepting a list of parameters(and probably vise-versa).
 > Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow tuple 
deconstructing
 > and then, as additive change improve the situation with tuple
 > splatting/deconstructing later with separate big proposal?
 >
 > Btw, about the SE-0110 proposal. It 

Re: [swift-evolution] Yet another fixed-size array spitball session

[Haravikk via swift-evolution]

> On 2 Jun 2017, at 07:38, Robert Bennett  wrote:
> 
> My favorite proposal so far is one that was posted a while ago, [Int * 4]. I 
> think that this syntax looks pretty Swifty. There isn't an oddball subscript 
> operator like with Int[4], and there isn't a need to allow generics to 
> support values as parameters. It's clear that [Int * 4] will be array-like 
> and contain four Ints. For multidimensional arrays we could use [Int * 
> (2,3)]. For an array of tuples, [(x: Int, y: Int) * 4]. I'm not sure why 
> nested static arrays would be needed when multidimentionality is provided out 
> of the box, but presumably the syntax would support them; you would just need 
> to subscript the arrays one at a time instead of with a single subscript 
> operator, e.g., a[i][j] instead of a[i, j].
> 
> I'm imagining this syntax working like [T] does now as a shorthand for 
> Array, although I'm not sure what [Int * 4] should be short for 
> (StaticArray? Vector4? ...). Constructors for static arrays 
> would be called using [Int * 4](args). I'm thinking the constructors would be 
> [T * 4](filledWith: T), [T * 4](filledBy: (Int)->T), and an initializer 
> taking a Sequence that fails in some manner on a dimension mismatch.

Even with that syntax I'd say there should be a means of handling it in a 
general purpose way.

For example, let's say you defined that syntax as an operator:

func * (lhs: T.self, rhs: Int) -> (type: T.self, size:Int) { return 
(type: lhs, size: rhs) }

Now you have an explicit tuple describing what it is you want to do, which the 
compiler can now pass to a type during compilation to do with as it pleases. In 
this case it would pass to some FixedArray type which can use the type and size 
to optimise itself. Not sure on the specifics of how just yet, but point being 
to try to make this a part of the language that others can use, rather than 
simply being some form of compiler magic.

My reasoning being that it may be useful to have other type operators in 
future, and/or other types able to take and use the same information.


For example, I briefly discussed once the possibility of a Float variant whose 
compatibility would be limited by its target precision, and use ± as an 
operator so that I could define for example:

var a:Float±0.1 = 0.5
var b:Float±0.5 = 5.0
a = b // error; precision mismatch (b's precision is too low to 
guarantee accuracy)
b = a // this is fine, as a is "more precise" than b


Now put aside whether that idea is actually useful or not; my point is that I'd 
like support for fixed-size arrays to be general purpose, as there are other 
possible uses for the same basic capabilities (i.e- type variables).

The key thing really is that we need some way for the compiler to recognise 
that a type is being refined somehow, and compile it separately as appropriate. 
I mentioned generics style variable passing because to me this is the most 
logical way to pass information into a type, not because I want it to be the 
default syntax at the call site; I fully support other shorthands for the 
actual passing of data, the key for me is being able to leverage the same kind 
of type-refining capabilities in my own types, rather than this whole thing 
just being focused solely on fixed-sized arrays implemented with compiler magic.

> On Jun 1, 2017, at 7:36 AM, Haravikk via swift-evolution 
> > wrote:
> 
>> Just wanted to add my two-cents to this discussion, but in terms of syntax I 
>> think that the basic method for specifying size should be with some kind of 
>> type variables, like so:
>> 
>>  struct MyFixedArray { … }
>> 
>> The idea being that we can then use size as a variable anywhere within the 
>> code for MyFixedArray, but unlike other variables it is determined at 
>> compile time, so should be optimised accordingly. As with generics, setting 
>> a type variable effectively creates a variant type so for example, a 
>> MyFixedArray and a MyFixedArray would no longer be 
>> directly compatible as they may differ internally.
>> 
>> This would be useful not just for fixed arrays, but other possibly type 
>> variations as well. Ideally it should be possible to specify a default value 
>> for type variables; while this wouldn't be useful for fixed arrays, it may 
>> be useful for other type variants.
>> 
>> To better suit the specific use-case of arrays, we could also add some 
>> useful attributes or keywords, for example, reusing subscript could give us:
>> 
>> struct MyFixedArray { … }
>> let foo:MyFixedArray[4] = [1, 2, 3, 4] // with T being inferred, this is a 
>> shorthand for specifying a size of 4
>> 
>> Type variables could also be usable with generics, like-so:
>> 
>> // only accept fixed arrays of same or smaller size:
>> func myMethod(values:FA) where FA:FixedArray, 

Re: [swift-evolution] Yet another fixed-size array spitball session

[Tino Heth via swift-evolution]

> 1. Magic tuple conformances: We already want to be able to automatically 
> conform tuples to protocols like Equatable, Hashable, and Comparable. These 
> can all be compiler magic; they don't have to be definable in userspace.
> 
> 2. Conform tuples to Collection: The Element type should be the most specific 
> common supertype of the tuple's elements. If all the elements are the same 
> type, it would be that type. The Index and IndexDistance types should be Int.
I always see tuples as some kind of anonymous struct, and those two have much 
more in common than with collections — so when tuples conform to collection, 
structs and classes should conform as well.
I'm just not sure what to think about that idea (might be useful, but could be 
terrible)

> 3. Conform same-type tuples to MutableCollection: If all elements are the 
> same type, you can also modify the values. (If their types vary in any way, 
> however, it would not be safe to allow mutations, since you could assign the 
> wrong type to an element.)
I think that's to confusing without much benefit in return.

> 4. Add sugar for a tuple of N identical elements: Probably something like `4 
> * Int`, but opinions can vary.
[small correction applied]
I strongly dislike all shortcuts that have been proposed, and think they don't 
pull their own weight.

For me, generics are definitely the best solution — maybe we should just 
declare literals to be types? ;-)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Self's nominal restriction denies significant feature patterns

[Zaid Daghestani via swift-evolution]

*edit*
Actual protocol implementation:

protocol Selfie {
init()
}
extension Selfie {
static func retOne() -> Self {return self.init()}
static func retMany() -> Array { return [] }
static func retTuple() -> (Self, Int) { return (self.init(), 0) }
}


> On Jun 2, 2017, at 3:08 AM, Zaid Daghestani  wrote:
> 
> Wow, you’re right. Look like this is a bug? The issue shows up in class 
> definitions, not protocol definitions.
> 
> This works:
> 
> protocol Selfie {
> static func retOne() -> Self
> static func retMany() -> Array
> static func retTuple() -> (Self, Int)
> }
> 
> This doesn’t work:
> 
> class Selfie {
> required init() {}
> // Compiles
> static func retOne() -> Self {return self.init()}
> // Doesn't Compile
> static func retMany() -> Array { return [] }
> // Doesn't Compile
> static func retTuple() -> (Self, Int) { return (self.init(), 0) }
> 
> }
> 
> So Self in non-nominal types with class methods end up with the compiler 
> error:
> 
> Error: 'Self' is only available in a protocol or as the result of a method in 
> a class; did you mean ’Selfie’?
> 
> Can we get confirmation from anyone?
> 
> 
> 
>> On Jun 2, 2017, at 2:39 AM, Gwendal Roué > > wrote:
>> 
>> Hello Zaid,
>> 
>> I don't know what prevents you from implementing your DAOs.
>> 
>> For an example of a library that uses them extensively, see 
>> http://github.com/groue/GRDB.swift: 
>> 
>> struct PointOfInterest {
>> var id: Int64?
>> var title: String?
>> var favorite: Bool
>> var coordinate: CLLocationCoordinate2D
>> }
>> 
>> // (snip) adopt protocols that turn PointOfInterest in a "record"
>> 
>> // Fetch from SQL
>> let pois = try PointOfInterest.fetchAll(db, "SELECT * FROM 
>> pointOfInterests") // [PointOfInterest]
>> 
>> // Fetch without SQL
>> let title = Column("title")
>> let favorite = Column("favorite")
>> let poi1 = try PointOfInterest.fetchOne(db, key: 1)   // 
>> PointOfInterest?
>> let pois = try PointOfInterest.fetchOne(db, keys: [1, 2, 3])  // 
>> [PointOfInterest]
>> let paris = try PointOfInterest.filter(title == "Paris").fetchOne(db) // 
>> PointOfInterest?
>> let favoritePois = try PointOfInterest// 
>> [PointOfInterest]
>> .filter(favorite)
>> .order(title)
>> .fetchAll(db)
>> 
>> // Insert, update, delete
>> var berlin = PointOfInterest(
>> id: nil,
>> title: "Berlin",
>> favorite: false,
>> coordinate: CLLocationCoordinate2DMake(52.52437, 13.41053))
>> try berlin.insert(db)
>> berlin.id // some value
>> berlin.favorite = true
>> try berlin.update(db)
>> try berlin.delete(db)
>> 
>> GRDB "records" work pretty well with structs, but also class hierarchies, 
>> without any caveat.
>> 
>> Can you explain a little more your issue ?
>> 
>> Gwendal Roué
>> 
>> 
>>> Le 2 juin 2017 à 11:18, Zaid Daghestani via swift-evolution 
>>> > a écrit :
>>> 
>>> Greetings Swift Community,
>>> 
>>> Today I’m throwing out a pitch on freeing the shackles on Self. Self is a 
>>> potentially significant tool that I am itching to implement in my patterns 
>>> to make my code more concise, clear and intuitive.
>>> 
>>> Self, by far, is cherished by Data Models and ORM's, and particularly DAO 
>>>  s (Ref. 1 for examples). There are a 
>>> significant amount of patterns in which a base class’s methods are Self 
>>> relevant and not generic relevant. Self being non-referrable in non-nominal 
>>> types denies significant feature and pattern delivery such as DAO. And to 
>>> deny implementation of a pattern as significant as DAO’s seems like a shot 
>>> in the foot. Adding Self to non-nominal types brings Collections and Async 
>>> to our class/protocol methods. A single query method returning a sync or 
>>> likely async collection on my DataModel class will be used in about 80% of 
>>> my app screens and 80% of my eerver API’s, almost all of the time. Hell 
>>> this even applies to struct patterns as well.
>>> 
>>> Now, DAO’s can actually already currently be achieved via generics, see 
>>> Ref. 2. This actually still a pretty good implementation, but Self is a 
>>> significantly more true implementation of these patterns. Issues with the 
>>> current generic pattern of Self relevancy in Swift is:
>>> 1- Generic methods in the base class are a workaround to the lack of Self. 
>>> The base class is not a class that implements generic patterns. It a base 
>>> class that implements Self patterns. Self is more concise and intuitive in 
>>> implementing a DAO or any other Self relevant base class.
>>> 2- Self relevant patterns are distinct and not the 

Re: [swift-evolution] [Pitch] Self's nominal restriction denies significant feature patterns

[Zaid Daghestani via swift-evolution]

Wow, you’re right. Look like this is a bug? The issue shows up in class 
definitions, not protocol definitions.  

This works:

protocol Selfie {
static func retOne() -> Self
static func retMany() -> Array
static func retTuple() -> (Self, Int)
}

This doesn’t work:

class Selfie {
required init() {}
// Compiles
static func retOne() -> Self {return self.init()}
// Doesn't Compile
static func retMany() -> Array { return [] }
// Doesn't Compile
static func retTuple() -> (Self, Int) { return (self.init(), 0) }

}

So Self in non-nominal types with class methods end up with the compiler error:

Error: 'Self' is only available in a protocol or as the result of a method in a 
class; did you mean ’Selfie’?

Can we get confirmation from anyone?



> On Jun 2, 2017, at 2:39 AM, Gwendal Roué  wrote:
> 
> Hello Zaid,
> 
> I don't know what prevents you from implementing your DAOs.
> 
> For an example of a library that uses them extensively, see 
> http://github.com/groue/GRDB.swift: 
> 
> struct PointOfInterest {
> var id: Int64?
> var title: String?
> var favorite: Bool
> var coordinate: CLLocationCoordinate2D
> }
> 
> // (snip) adopt protocols that turn PointOfInterest in a "record"
> 
> // Fetch from SQL
> let pois = try PointOfInterest.fetchAll(db, "SELECT * FROM 
> pointOfInterests") // [PointOfInterest]
> 
> // Fetch without SQL
> let title = Column("title")
> let favorite = Column("favorite")
> let poi1 = try PointOfInterest.fetchOne(db, key: 1)   // 
> PointOfInterest?
> let pois = try PointOfInterest.fetchOne(db, keys: [1, 2, 3])  // 
> [PointOfInterest]
> let paris = try PointOfInterest.filter(title == "Paris").fetchOne(db) // 
> PointOfInterest?
> let favoritePois = try PointOfInterest// 
> [PointOfInterest]
> .filter(favorite)
> .order(title)
> .fetchAll(db)
> 
> // Insert, update, delete
> var berlin = PointOfInterest(
> id: nil,
> title: "Berlin",
> favorite: false,
> coordinate: CLLocationCoordinate2DMake(52.52437, 13.41053))
> try berlin.insert(db)
> berlin.id // some value
> berlin.favorite = true
> try berlin.update(db)
> try berlin.delete(db)
> 
> GRDB "records" work pretty well with structs, but also class hierarchies, 
> without any caveat.
> 
> Can you explain a little more your issue ?
> 
> Gwendal Roué
> 
> 
>> Le 2 juin 2017 à 11:18, Zaid Daghestani via swift-evolution 
>> > a écrit :
>> 
>> Greetings Swift Community,
>> 
>> Today I’m throwing out a pitch on freeing the shackles on Self. Self is a 
>> potentially significant tool that I am itching to implement in my patterns 
>> to make my code more concise, clear and intuitive.
>> 
>> Self, by far, is cherished by Data Models and ORM's, and particularly DAO 
>>  s (Ref. 1 for examples). There are a 
>> significant amount of patterns in which a base class’s methods are Self 
>> relevant and not generic relevant. Self being non-referrable in non-nominal 
>> types denies significant feature and pattern delivery such as DAO. And to 
>> deny implementation of a pattern as significant as DAO’s seems like a shot 
>> in the foot. Adding Self to non-nominal types brings Collections and Async 
>> to our class/protocol methods. A single query method returning a sync or 
>> likely async collection on my DataModel class will be used in about 80% of 
>> my app screens and 80% of my eerver API’s, almost all of the time. Hell this 
>> even applies to struct patterns as well.
>> 
>> Now, DAO’s can actually already currently be achieved via generics, see Ref. 
>> 2. This actually still a pretty good implementation, but Self is a 
>> significantly more true implementation of these patterns. Issues with the 
>> current generic pattern of Self relevancy in Swift is:
>> 1- Generic methods in the base class are a workaround to the lack of Self. 
>> The base class is not a class that implements generic patterns. It a base 
>> class that implements Self patterns. Self is more concise and intuitive in 
>> implementing a DAO or any other Self relevant base class.
>> 2- Self relevant patterns are distinct and not the same as Generic patterns. 
>> 3- In usage of a DAO, the generic pattern requires that the Left Hand Side 
>> be typed to collapse the generic. In the case of Self relevance, the 
>> particular class name is enough. Swift, being an inference language, would 
>> be truer with the Self system, and not the repetitive type declaration style 
>> of ObjC/Java that generics provide.
>> let friends = User.where("id IN %@", friendIds) // truer to Swift type 
>> inference
>> // vs.
>> let friends:[User] = User.where("id IN %@", friendIds) // 

Re: [swift-evolution] Sparse (fixed-size) array literal syntax

[Daryle Walker via swift-evolution]

> On Jun 2, 2017, at 4:06 AM, Jaden Geller  wrote:
> 
> I don’t know if you’re aware, but you can extend arbitrary nominal types with 
> literal syntax.
> 
> ```
> extension FixedSizedArray: ExpressibleAsDictionaryLiteral { … }
> ```
> 
> Nothing special needs to be done on the implementation side to make this 
> possible. If fixed sized arrays are not nominal types (like tuples, unlike 
> `Array`s), then you will only be able to give this sugar to types that wrap 
> them, not the type itself (w/o special support).

I don’t think that’ll work with the “where” clauses and “default” values in the 
new syntax.

> What’s the discussion on enhanced array and dictionary literals? I think I 
> missed that.

This is the discussion. I’m asking if this “enhanced array” syntax I just came 
up with would interfere with the existing dictionary syntax from a parsing 
perspective.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] Self's nominal restriction denies significant feature patterns

[Gwendal Roué via swift-evolution]

Hello Zaid,

I don't know what prevents you from implementing your DAOs.

For an example of a library that uses them extensively, see 
http://github.com/groue/GRDB.swift:

struct PointOfInterest {
var id: Int64?
var title: String?
var favorite: Bool
var coordinate: CLLocationCoordinate2D
}

// (snip) adopt protocols that turn PointOfInterest in a "record"

// Fetch from SQL
let pois = try PointOfInterest.fetchAll(db, "SELECT * FROM 
pointOfInterests") // [PointOfInterest]

// Fetch without SQL
let title = Column("title")
let favorite = Column("favorite")
let poi1 = try PointOfInterest.fetchOne(db, key: 1)   // 
PointOfInterest?
let pois = try PointOfInterest.fetchOne(db, keys: [1, 2, 3])  // 
[PointOfInterest]
let paris = try PointOfInterest.filter(title == "Paris").fetchOne(db) // 
PointOfInterest?
let favoritePois = try PointOfInterest// 
[PointOfInterest]
.filter(favorite)
.order(title)
.fetchAll(db)

// Insert, update, delete
var berlin = PointOfInterest(
id: nil,
title: "Berlin",
favorite: false,
coordinate: CLLocationCoordinate2DMake(52.52437, 13.41053))
try berlin.insert(db)
berlin.id // some value
berlin.favorite = true
try berlin.update(db)
try berlin.delete(db)

GRDB "records" work pretty well with structs, but also class hierarchies, 
without any caveat.

Can you explain a little more your issue ?

Gwendal Roué


> Le 2 juin 2017 à 11:18, Zaid Daghestani via swift-evolution 
>  a écrit :
> 
> Greetings Swift Community,
> 
> Today I’m throwing out a pitch on freeing the shackles on Self. Self is a 
> potentially significant tool that I am itching to implement in my patterns to 
> make my code more concise, clear and intuitive.
> 
> Self, by far, is cherished by Data Models and ORM's, and particularly DAO 
>  s (Ref. 1 for examples). There are a 
> significant amount of patterns in which a base class’s methods are Self 
> relevant and not generic relevant. Self being non-referrable in non-nominal 
> types denies significant feature and pattern delivery such as DAO. And to 
> deny implementation of a pattern as significant as DAO’s seems like a shot in 
> the foot. Adding Self to non-nominal types brings Collections and Async to 
> our class/protocol methods. A single query method returning a sync or likely 
> async collection on my DataModel class will be used in about 80% of my app 
> screens and 80% of my eerver API’s, almost all of the time. Hell this even 
> applies to struct patterns as well.
> 
> Now, DAO’s can actually already currently be achieved via generics, see Ref. 
> 2. This actually still a pretty good implementation, but Self is a 
> significantly more true implementation of these patterns. Issues with the 
> current generic pattern of Self relevancy in Swift is:
> 1- Generic methods in the base class are a workaround to the lack of Self. 
> The base class is not a class that implements generic patterns. It a base 
> class that implements Self patterns. Self is more concise and intuitive in 
> implementing a DAO or any other Self relevant base class.
> 2- Self relevant patterns are distinct and not the same as Generic patterns. 
> 3- In usage of a DAO, the generic pattern requires that the Left Hand Side be 
> typed to collapse the generic. In the case of Self relevance, the particular 
> class name is enough. Swift, being an inference language, would be truer with 
> the Self system, and not the repetitive type declaration style of ObjC/Java 
> that generics provide.
> let friends = User.where("id IN %@", friendIds) // truer to Swift type 
> inference
> // vs.
> let friends:[User] = User.where("id IN %@", friendIds) // Java/Objective-C 
> style repetitive type declarations
> 
> Let’s break the chains on Self! It is extremely intuitive, and we are all 
> going to use it
> 
> Peace!
> 
> Z
> 
> 
> 
> 
> Ref 1: DAO patterns::
> 
> class DataModelObject  {
> 
> /* One of the most significant use cases
>  * Retrieving a queried on collection asynchronusly
>  */
> class func `where`(_ predicate:String, _ args:CVarArg...) -> 
> Promise<[Self]> {
> // querie
> return Promise(value: [[])
> }
> 
> // some more examples
> 
> // optional async get
> class func get(id:String) -> Promise {
> return Promise(value:self.init(id:id))
> }
> 
> // sync all collection
> class func all() -> [Self] {
> return []
> }
> // asynnchronous fetch
> class func allAsync() -> Promise<[Self]> {
> return Promise(value: [])
> }
> 
> // in the case of RealmDB we have returns of Results, a lazy 
> collection
> class func `where`(_ predication:NSPredicate) -> Results {
> return Results()
> }

Re: [swift-evolution] Yet another fixed-size array spitball session

[Zaid Daghestani via swift-evolution]

Just a small question, named tuples => Dictionary? Or how would that resolve?
> On Jun 2, 2017, at 2:20 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution 
>> > wrote:
>> 
>> Static-Sized Arrays
> 
> My preference would still be to build this from four separate features:
> 
> 1. Magic tuple conformances: We already want to be able to automatically 
> conform tuples to protocols like Equatable, Hashable, and Comparable. These 
> can all be compiler magic; they don't have to be definable in userspace.
> 
> 2. Conform tuples to Collection: The Element type should be the most specific 
> common supertype of the tuple's elements. If all the elements are the same 
> type, it would be that type. The Index and IndexDistance types should be Int.
> 
> 3. Conform same-type tuples to MutableCollection: If all elements are the 
> same type, you can also modify the values. (If their types vary in any way, 
> however, it would not be safe to allow mutations, since you could assign the 
> wrong type to an element.)
> 
> 3. Add sugar for a tuple of N identical elements: Probably something like `4 
> * Int`, but opinions can vary.
> 
> This solution avoids adding another structural type to the language or 
> introducing non-type generic parameters. It also addresses other needs: 1 and 
> 2 are desirable features in their own right which address other use cases in 
> addition to this one. And it's nicely incremental, which is always a plus.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Yet another fixed-size array spitball session

[Daryle Walker via swift-evolution]

New Spitball

But first:

C has one of the worst array presentation models. It has traumatized so many 
that those among them that grew up to be language designers themselves threw 
out fixed-sized arrays entirely (from Java to even current Swift!). But we’re 
getting through to everyone that the concept is still important, no matter how 
bad one realization of it is.

* If you could to arrays over, why limit your indexes to 0 ..< COUNT, when you 
could use any range by subtracting an offset first
* Once you do that, why limit yourself to Int, when anything that could be 
implemented as an Int (like an enumeration type) would also work.

The whole point of adding types is abstraction. If you are modeling a table 
where the coordinates are an enumeration, why not let the language to the 
translation for you. There’s no need for just a Swift-y version of C’s array 
model. (Already Swift downplays pointers, so the “arrays are pointers with 
funny settings” part of the C model shouldn’t be carried over.)

This isn’t a new concept; while C’s successors gave up, C’s contemporaries 
didn’t. There’s plenty of models to base array presentation on. Looking at an 
Ada page recently, I realized that I must have let my previous experience shape 
the keywords I chose.

Now back to Spitball #3:

New Keywords:
* of
* #indexOf
* #flatten

Static Array Directive:
* “[“ Specifiers_opt “of” type “]”
* Specifiers: Specifier | Specifier “,” Specifiers
* Specifier: Extent-Range Storage-Rank_opt
* Extent-Range: Low … High | Low ..< High | N (for 0 ..< N) | Enum-Type (for 
Enum.min … Enum.max)
* Storage-Rank: Integer in 0 ..< ExtentCount; use smallest unused value if 
missing; all values must be used exactly once
* “mutating” (or “nonmutating”) can precede the type if the directive is used 
for an array-segment reference

Immediate Array: Use Static Array Directive with at least one extent

Array-Segment Reference: Use Static Array Directive with no extents
* can initialize a scoped reference with an array literal, but the reference 
must be in “let” mode (so you can’t reseat it and lose the only reference to 
the array)
* If you use this construct, put in a “mutating” to let the elements be 
changeable if needed
* This will let you use a C-like “let myArray: [of mutating Int] = [1, 2, 3, 4, 
6]” without counting first, like “var myArray: [5 of Int] = [1, 2, 3, 4, 6]” 
would need

Nominal Arrays: Use “struct” with a Static Array Directive as the base type; 
mutually exclusive with instance-level stored properties (Having neither is OK.)
* The “subscript” definition allows zero parameters, but “[]” doesn’t allow 
zero arguments, so use “myArray.super” to get the inner singular value in this 
case
* Swift allows “self” by itself, but not “super”. This will have to be changed.

For loops:
* Array-segment references conform to RandomAccessCollection (and possibly 
MutableCollection); the two definitive array types don’t
* For loops will work for the definitive array types anyway
* We should either define iteration in storage order or let it be 
implementation-defined
* We should have some other syntax to let processing of elements go in parallel
* Within a for-loop, use “#indexOf(X)” to get a tuple of the index coordinates 
of the current element; “X” is (one of) the iteration objects between the “for” 
and “in”; an identifier is needed so if you have nested for-loops with separate 
arrays, you can choose which one to inspect

Dereferencing:
* For immediate arrays, use "myArray.0" like tuples, it’s "myArray.(1, 2)" for 
multi-dimensional arrays
* Convert to array-segment first if you need run-time index selection (with 
“[]”)
* Nominal arrays come with “[]” by default

Function arguments:
* Use array-segment reference parameter to take definitive arrays of any size, 
assuming the same element type
* If the definitive array is multi-dimensional, use “#flatten(myArray)” first 
(I’ve realized that a multi-D array should not translate to a linear ASR 
silently by default.)
* Of course, you can use either definitive array type as a parameter too

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[Brent Royal-Gordon via swift-evolution]

> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> Static-Sized Arrays

My preference would still be to build this from four separate features:

1. Magic tuple conformances: We already want to be able to automatically 
conform tuples to protocols like Equatable, Hashable, and Comparable. These can 
all be compiler magic; they don't have to be definable in userspace.

2. Conform tuples to Collection: The Element type should be the most specific 
common supertype of the tuple's elements. If all the elements are the same 
type, it would be that type. The Index and IndexDistance types should be Int.

3. Conform same-type tuples to MutableCollection: If all elements are the same 
type, you can also modify the values. (If their types vary in any way, however, 
it would not be safe to allow mutations, since you could assign the wrong type 
to an element.)

3. Add sugar for a tuple of N identical elements: Probably something like `4 * 
Int`, but opinions can vary.

This solution avoids adding another structural type to the language or 
introducing non-type generic parameters. It also addresses other needs: 1 and 2 
are desirable features in their own right which address other use cases in 
addition to this one. And it's nicely incremental, which is always a plus.

-- 
Brent Royal-Gordon
Architechies

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

[swift-evolution] [Pitch] Self's nominal restriction denies significant feature patterns

[Zaid Daghestani via swift-evolution]

Greetings Swift Community,

Today I’m throwing out a pitch on freeing the shackles on Self. Self is a 
potentially significant tool that I am itching to implement in my patterns to 
make my code more concise, clear and intuitive.

Self, by far, is cherished by Data Models and ORM's, and particularly DAO 
 s (Ref. 1 for examples). There are a 
significant amount of patterns in which a base class’s methods are Self 
relevant and not generic relevant. Self being non-referrable in non-nominal 
types denies significant feature and pattern delivery such as DAO. And to deny 
implementation of a pattern as significant as DAO’s seems like a shot in the 
foot. Adding Self to non-nominal types brings Collections and Async to our 
class/protocol methods. A single query method returning a sync or likely async 
collection on my DataModel class will be used in about 80% of my app screens 
and 80% of my eerver API’s, almost all of the time. Hell this even applies to 
struct patterns as well.

Now, DAO’s can actually already currently be achieved via generics, see Ref. 2. 
This actually still a pretty good implementation, but Self is a significantly 
more true implementation of these patterns. Issues with the current generic 
pattern of Self relevancy in Swift is:
1- Generic methods in the base class are a workaround to the lack of Self. The 
base class is not a class that implements generic patterns. It a base class 
that implements Self patterns. Self is more concise and intuitive in 
implementing a DAO or any other Self relevant base class.
2- Self relevant patterns are distinct and not the same as Generic patterns. 
3- In usage of a DAO, the generic pattern requires that the Left Hand Side be 
typed to collapse the generic. In the case of Self relevance, the particular 
class name is enough. Swift, being an inference language, would be truer with 
the Self system, and not the repetitive type declaration style of ObjC/Java 
that generics provide.
let friends = User.where("id IN %@", friendIds) // truer to Swift type inference
// vs.
let friends:[User] = User.where("id IN %@", friendIds) // Java/Objective-C 
style repetitive type declarations

Let’s break the chains on Self! It is extremely intuitive, and we are all going 
to use it

Peace!

Z




Ref 1: DAO patterns::

class DataModelObject  {

/* One of the most significant use cases
 * Retrieving a queried on collection asynchronusly
 */
class func `where`(_ predicate:String, _ args:CVarArg...) -> 
Promise<[Self]> {
// querie
return Promise(value: [[])
}

// some more examples

// optional async get
class func get(id:String) -> Promise {
return Promise(value:self.init(id:id))
}

// sync all collection
class func all() -> [Self] {
return []
}
// asynnchronous fetch
class func allAsync() -> Promise<[Self]> {
return Promise(value: [])
}

// in the case of RealmDB we have returns of Results, a lazy 
collection
class func `where`(_ predication:NSPredicate) -> Results {
return Results()
}
}

class User : DataMadelObject {
dynamic var id:String = ""
dynamic var name:String = ""
}

let friendIds = [1, 2, 3]
let friends = User.where("id IN %@", friendIds)

Ref 2: Currently implementable DAO

class DataModelObject  {

/* One of the most significant use cases
 * Retrieving a queried on collection asynchronusly
 */
class func `where`(_ predicate:String, _ 
args:CVarArg...) -> Promise<[T]> {
// querie
return Promise(value: [])
}

// some more examples
// optional async get
class func get(id:String) -> Promise {
return Promise(value:self.init(id:id))
}


// sync all collection
class func all() -> [T] {
return []
}
// asynnchronous fetch
class func allAsync() -> Promise<[T]> {
return Promise(value: [])
}

// in the case of RealmDB we have returns of Results, a lazy 
collection
class func `where`(_ predication:NSPredicate) -> 
Results {
return Results()
}
}

class User : DataMadelObject {
dynamic var id:String = ""
dynamic var name:String = ""
}

let friendIds = [1, 2, 3]
let friends:[User] = User.where("id IN %@", friendIds)


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

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel Rodríguez via swift-evolution]

On Fri, Jun 2, 2017 at 1:53 AM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> I vote to revert it to current behavior.  Then we can take time to come up
> with the correct answer for future Swift.
>
> If we don’t revert and then end up changing it again later, we will break
> everybody’s code twice...
>
> Thanks,
> Jon
>

+1

This source-breaking change affects lots of libraries, as it has been
shown. It seems very late in Swift 4 to be discussing alternative syntaxes,
so the best action for me would be revert it and revisit this in the next
version.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Sparse (fixed-size) array literal syntax

[Jaden Geller via swift-evolution]

Why would this not be possible with fixed sized arrays? Theoretically you could 
create a type that wrapped a fixed array and make it conform to whatever 
protocol you want, including the “ExpressibleBy” protocols.

> On Jun 2, 2017, at 12:22 AM, Daryle Walker  wrote:
> 
>> 
>> On Jun 2, 2017, at 2:11 AM, Jaden Geller > > wrote:
>> 
>> Comments inline.
>> 
>>> On Jun 1, 2017, at 10:49 PM, Daryle Walker via swift-evolution 
>>> > wrote:
>>> 
>>> Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or 
>>> linear arrays, but isn’t so great later on when we add fixed-size arrays 
>>> and the defined (non-zero) elements are sparse and/or the array is 
>>> multi-dimensional (not nested). In these cases I’m thinking of leading each 
>>> element with its coordinate:
>>> 
>>> … 6: a, …  // complete value, linear array
>> 
>> You can already do this with a dictionary since a Int can be used as the key 
>> type.
>> 
>>> … (1, 2): b, …  // complete value, multi-dimensional array
>> 
>> This would be possible if tuples of hashable types were considered hahable. 
>> Right now, you could define some point type.
>> 
>>> … (let x, let y) where y % 2 == 0: c * y + x, …  // pattern of qualifying 
>>> coordinates
>> 
>> You can build this sort of thing using an initializer that takes a function. 
>> You wouldn’t get this sugar, but I don’t think it is necessary.
>> 
>>> … default: d, …  // when no other initializer covers an element (Use “_” 
>>> instead?)
>> 
>> This one is a bit harder. I think it would be reasonable for there to exist 
>> some subtype of the dictionary literal type that also included information 
>> about a default value, but I think this should be motivated by the Swift 
>> standard library (e.g. a defaultable dictionary type).
>> 
>> Right now, you can just make literal syntax default to a `nil` default 
>> value, and then you can define a function that nil-coalesces the default 
>> value. This is definitely less elegant, but I don’t think it matters a whole 
>> lot.
>> ```
>> Sparse([1: “foo”, 5: “bar”, 100: “baz”], default: “”)
>> ```
> 
> I’m not asking how to do this in current Swift with current types, but 
> fixed-sized arrays in a future Swift. I’m asking if this mixing of array- and 
> dictionary-literals for these advanced-array literals would be too hard for 
> compiler implementors to implement.
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 

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

Re: [swift-evolution] Sparse (fixed-size) array literal syntax

[Daryle Walker via swift-evolution]

> On Jun 2, 2017, at 3:56 AM, Jaden Geller  wrote:
> 
> Why would this not be possible with fixed sized arrays? Theoretically you 
> could create a type that wrapped a fixed array and make it conform to 
> whatever protocol you want, including the “ExpressibleBy” protocols.

I DO want it to be possible with future fixed-sized arrays. This is not a 
user-side question, but implementor-side. I’m asking if the parsing routines 
for it would conflict with the current array- and dictionary-literal rules, 
since they will co-exist. If this syntax would make determining whether we have 
an enhanced array literal or a dictionary literal too hard, then we should 
change it before anything is finalized.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Sparse (fixed-size) array literal syntax

[Jaden Geller via swift-evolution]

I don’t know if you’re aware, but you can extend arbitrary nominal types with 
literal syntax.

```
extension FixedSizedArray: ExpressibleAsDictionaryLiteral { … }
```

Nothing special needs to be done on the implementation side to make this 
possible. If fixed sized arrays are not nominal types (like tuples, unlike 
`Array`s), then you will only be able to give this sugar to types that wrap 
them, not the type itself (w/o special support).

What’s the discussion on enhanced array and dictionary literals? I think I 
missed that.

Cheers,
Jaden Geller

> On Jun 2, 2017, at 1:02 AM, Daryle Walker  wrote:
> 
> 
>> On Jun 2, 2017, at 3:56 AM, Jaden Geller  wrote:
>> 
>> Why would this not be possible with fixed sized arrays? Theoretically you 
>> could create a type that wrapped a fixed array and make it conform to 
>> whatever protocol you want, including the “ExpressibleBy” protocols.
> 
> I DO want it to be possible with future fixed-sized arrays. This is not a 
> user-side question, but implementor-side. I’m asking if the parsing routines 
> for it would conflict with the current array- and dictionary-literal rules, 
> since they will co-exist. If this syntax would make determining whether we 
> have an enhanced array literal or a dictionary literal too hard, then we 
> should change it before anything is finalized.
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 

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

Re: [swift-evolution] Sparse (fixed-size) array literal syntax

[Daryle Walker via swift-evolution]

> On Jun 2, 2017, at 2:11 AM, Jaden Geller  wrote:
> 
> Comments inline.
> 
>> On Jun 1, 2017, at 10:49 PM, Daryle Walker via swift-evolution 
>> > wrote:
>> 
>> Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or 
>> linear arrays, but isn’t so great later on when we add fixed-size arrays and 
>> the defined (non-zero) elements are sparse and/or the array is 
>> multi-dimensional (not nested). In these cases I’m thinking of leading each 
>> element with its coordinate:
>> 
>> … 6: a, …  // complete value, linear array
> 
> You can already do this with a dictionary since a Int can be used as the key 
> type.
> 
>> … (1, 2): b, …  // complete value, multi-dimensional array
> 
> This would be possible if tuples of hashable types were considered hahable. 
> Right now, you could define some point type.
> 
>> … (let x, let y) where y % 2 == 0: c * y + x, …  // pattern of qualifying 
>> coordinates
> 
> You can build this sort of thing using an initializer that takes a function. 
> You wouldn’t get this sugar, but I don’t think it is necessary.
> 
>> … default: d, …  // when no other initializer covers an element (Use “_” 
>> instead?)
> 
> This one is a bit harder. I think it would be reasonable for there to exist 
> some subtype of the dictionary literal type that also included information 
> about a default value, but I think this should be motivated by the Swift 
> standard library (e.g. a defaultable dictionary type).
> 
> Right now, you can just make literal syntax default to a `nil` default value, 
> and then you can define a function that nil-coalesces the default value. This 
> is definitely less elegant, but I don’t think it matters a whole lot.
> ```
> Sparse([1: “foo”, 5: “bar”, 100: “baz”], default: “”)
> ```

I’m not asking how to do this in current Swift with current types, but 
fixed-sized arrays in a future Swift. I’m asking if this mixing of array- and 
dictionary-literals for these advanced-array literals would be too hard for 
compiler implementors to implement.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[Robert Bennett via swift-evolution]

My favorite proposal so far is one that was posted a while ago, [Int * 4]. I 
think that this syntax looks pretty Swifty. There isn't an oddball subscript 
operator like with Int[4], and there isn't a need to allow generics to support 
values as parameters. It's clear that [Int * 4] will be array-like and contain 
four Ints. For multidimensional arrays we could use [Int * (2,3)]. For an array 
of tuples, [(x: Int, y: Int) * 4]. I'm not sure why nested static arrays would 
be needed when multidimentionality is provided out of the box, but presumably 
the syntax would support them; you would just need to subscript the arrays one 
at a time instead of with a single subscript operator, e.g., a[i][j] instead of 
a[i, j].

I'm imagining this syntax working like [T] does now as a shorthand for 
Array, although I'm not sure what [Int * 4] should be short for 
(StaticArray? Vector4? ...). Constructors for static arrays would 
be called using [Int * 4](args). I'm thinking the constructors would be [T * 
4](filledWith: T), [T * 4](filledBy: (Int)->T), and an initializer taking a 
Sequence that fails in some manner on a dimension mismatch.


> On Jun 1, 2017, at 7:36 AM, Haravikk via swift-evolution 
>  wrote:
> 
> Just wanted to add my two-cents to this discussion, but in terms of syntax I 
> think that the basic method for specifying size should be with some kind of 
> type variables, like so:
> 
>   struct MyFixedArray { … }
> 
> The idea being that we can then use size as a variable anywhere within the 
> code for MyFixedArray, but unlike other variables it is determined at compile 
> time, so should be optimised accordingly. As with generics, setting a type 
> variable effectively creates a variant type so for example, a 
> MyFixedArray and a MyFixedArray would no longer be 
> directly compatible as they may differ internally.
> 
> This would be useful not just for fixed arrays, but other possibly type 
> variations as well. Ideally it should be possible to specify a default value 
> for type variables; while this wouldn't be useful for fixed arrays, it may be 
> useful for other type variants.
> 
> To better suit the specific use-case of arrays, we could also add some useful 
> attributes or keywords, for example, reusing subscript could give us:
> 
> struct MyFixedArray { … }
> let foo:MyFixedArray[4] = [1, 2, 3, 4] // with T being inferred, this is a 
> shorthand for specifying a size of 4
> 
> Type variables could also be usable with generics, like-so:
> 
> // only accept fixed arrays of same or smaller size:
> func myMethod(values:FA) where FA:FixedArray, FA.size <= Self.size { … } 
> 
> These are the kind of general purpose capabilities I'd like to see at some 
> point, as the usefulness extends beyond just fixed-size arrays.
> 
> 
> 
> However, on the  subject of fixed-size arrays specifically, one other 
> possibility to explore is the concept of Tuple repetition and subscripting. 
> For example, it would be interesting if we could do things like:
> 
>   var foo:(Int)[4] = 0 // Initialises four Ints, all set initially to zero
>   for i in 0 ..< 4 { foo[i] = i } // values are no 0, 1, 2, 3
> 
> This can be especially interesting when you get into more complex tuples like 
> so:
> 
>   var bar:(x:Int, y:Int)[10] = (x: 0, y: 0) // Initialises 10 pairs of 
> Ints, all initially set to zero
>   for i in 0 ..< 10 { bar[i].x = i; bar[i].y = i } // here we need to use 
> .x and .y to access the values of each pair
> 
> Of course this would have the same performance characteristics as standard 
> tuples, but it's an interesting means for creating quick, fixed-size arrays 
> in a flexible way. Part of the idea here is that by subscripting tuples, we 
> avoid the need for a general subscript on all types, keeping that available 
> for use-cases like the above.
> ___
> 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] Sparse (fixed-size) array literal syntax

[Jaden Geller via swift-evolution]

Comments inline.

> On Jun 1, 2017, at 10:49 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or linear 
> arrays, but isn’t so great later on when we add fixed-size arrays and the 
> defined (non-zero) elements are sparse and/or the array is multi-dimensional 
> (not nested). In these cases I’m thinking of leading each element with its 
> coordinate:
> 
> … 6: a, …  // complete value, linear array

You can already do this with a dictionary since a Int can be used as the key 
type.

> … (1, 2): b, …  // complete value, multi-dimensional array

This would be possible if tuples of hashable types were considered hahable. 
Right now, you could define some point type.

> … (let x, let y) where y % 2 == 0: c * y + x, …  // pattern of qualifying 
> coordinates

You can build this sort of thing using an initializer that takes a function. 
You wouldn’t get this sugar, but I don’t think it is necessary.

> … default: d, …  // when no other initializer covers an element (Use “_” 
> instead?)

This one is a bit harder. I think it would be reasonable for there to exist 
some subtype of the dictionary literal type that also included information 
about a default value, but I think this should be motivated by the Swift 
standard library (e.g. a defaultable dictionary type).

Right now, you can just make literal syntax default to a `nil` default value, 
and then you can define a function that nil-coalesces the default value. This 
is definitely less elegant, but I don’t think it matters a whole lot.
```
Sparse([1: “foo”, 5: “bar”, 100: “baz”], default: “”)
```

> 
> A complete coordinate beats a pattern, which beats a default. The issue I see 
> here is that I’m using a colon as a separator between the coordinate 
> expression and the value expression. Would that interfere with dictionary 
> literal syntax? Would it help the we’ll most likely have to demand that the 
> object receiving the literal has to have its type specified (with whatever 
> syntax we agree on), as either a declared object with a type annotation or a 
> function parameter (for a function either without overload or with the 
> variant used otherwise made clear)?
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Cheers,
Jaden Geller

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