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

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++. —

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

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

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

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

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

> 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

Re: [swift-evolution] Revisiting SE-0110

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

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

> 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

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

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

Re: [swift-evolution] Revisiting SE-0110

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

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

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

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

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

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

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 {

Re: [swift-evolution] Revisiting SE-0110

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

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

> 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

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

> 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

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

*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,

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

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 {

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

> 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

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

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

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

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

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

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

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

> 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

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

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

Re: [swift-evolution] Revisiting SE-0110

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

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

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

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

> 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”

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

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

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

> 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]”)

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

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

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

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