date:20171214

[swift-evolution] Discourse rollout re-schedule

2017-12-14 Thread Nicole Jacque via swift-evolution

Hi All-

First of all, a big thank you to everyone who has provided feedback on our 
prototype Discourse forum.  Based on the fact that we’re still receiving 
feedback, we’d like to move to a slightly less aggressive schedule for our 
rollout, in order to make sure that we’ve adequately addressed it.  We’re still 
working out an exact schedule, but due to the upcoming holidays, I expect that 
we’ll be looking at shortly after the beginning of the new year.

In the meantime, I’ve moved the prototype forum to https://forums.swift.org, 
and I have GitHub-enabled logins working if you’d like to give it a try!  You 
can also test out registering (including using the staged account pre-created 
from your mailing list account).  Instructions are here: 
https://forums.swift.org/t/taking-over-a-pre-created-staged-account/7121

Once you’ve created an account, you’ll be able to experiment with the various 
account and notification settings that are available to you.

If you have feedback or see any issues, (especially with login) please file 
issues/comments/requests at bugs.swift.org under the “Project Infrastructure” 
component for tracking.

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

Re: [swift-evolution] [swift-dev] Make offset index available for String

2017-12-14 Thread Cao, Jiannan via swift-evolution

Sorry for my unclear "offset indexable".
So what I mean by "offset indexable" is providing a "collection-element level 
offset indexing". This indexing could provide to any collection, because it is 
the basic concept of collections.
The unicode offset is different than it and is important to String. Thus I just 
want the team to consider providing collections with the collection-element 
level offset indexing as an assistant to String.Index (which is the unicode 
level offset indexing).

> 在 2017年12月15日，上午9:34，Michael Ilseman  > 写道：
> 
> Yes, I was trying to highlight that they are different and should be treated 
> different. This was because it seemed you were conflating the two in your 
> argument. You claim that people expect it, and I’m pointing out that what 
> people actually expect (assuming they’re coming from C or languages with a 
> similar model) already exists as those models deal in encoded offsets.
> 
> More important than expectations surrounding what to provide to a subscript 
> are expectations surrounding algorithmic complexity. This has security 
> implications. The expectation of subscript is that it is “constant-ish”, for 
> a fuzzy hand-wavy definition of “constant-ish” which includes amortized 
> constant or logarithmic.
> 
> Now, I agree with the overall sentiment that `index(offsetBy:)` is unwieldy. 
> I am interested in approaches to improve this. But, we cannot throw linear 
> complexity into subscript without extreme justification.
> 
> 
>> On Dec 14, 2017, at 5:25 PM, Cao, Jiannan > > wrote:
>> 
>> This offset is unicode offset, is not the offset of element. 
>> For example: index(startIndex, offsetBy:1) is encodedOffset 4 or 8, not 1.
>> 
>> Offset indexable is based on the offset of count of each element/index. it 
>> is the same result of s.index(s.startIndex, offsetBy:i)
>> The encodedOffset is the underlaying offset of unicode string, not the same 
>> concept of the offset index of collection.
>> 
>> The offset indexable is meaning to the elements and index of collection 
>> (i-th element of the collection), not related to the unicode offset (which 
>> is the underlaying data offset meaning to the UTF-16 String).
>> 
>> These two offset is totally different.
>> 
>> Best,
>> Jiannan
>> 
>>> 在 2017年12月15日，上午9:17，Michael Ilseman >> > 写道：
>>> 
>>> 
>>> 
 On Dec 14, 2017, at 4:49 PM, Cao, Jiannan via swift-dev 
 > wrote:

 People used to the offset index system instead of the String.Index. Using 
 offset indices to name the elements, count the elements is normal and 
 nature.

>>> 
>>> The offset system that you’re referring to is totally available in String 
>>> today, if you’re willing for it to be the offset into the encoding. That’s 
>>> the offset “people” you’re referring to are likely used to and consider 
>>> normal and natural. On String.Index, there is the following:
>>> 
>>> init(encodedOffset offset: Int 
>>> )
>>> 
>>> and 
>>> 
>>> var encodedOffset: Int 
>>>  { get }
>>> 
>>> 
>>> [1] https://developer.apple.com/documentation/swift/string.index 
>>> 
>>> 
>>> 
 This offset index system has a long history and a real meaning to the 
 collection. The subscript s[i] has a fix meaning of "getting the i-th 
 element in this collection", which is normal and direct. Get the range 
 with offset indices, is also direct. It means the substring is from the 
 i-th character up to the j-th character of the original string.

 People used to play subscript, range with offset indices. Use 
 string[string.index(i, offsetBy: 5)] is not as directly and easily as 
 string[i + 5]. Also the Range is not as directly as 
 Range. Developers need to transfer the Range result 
 of string.range(of:) to Range to know the exact range of the 
 substring. Range has a real meaning to the machine and 
 underlaying data location for the substring, but Range also 
 has a direct location information for human being, and represents the 
 abstract location concept of the collection (This is the most 
 UNIMPEACHABLE REASON I could provide).

 Offset index system is based on the nature of collection. Each element of 
 the collection could be located by offset, which is a direct and simple 
 conception to any collection. Right? Even the String with String.Index has 
 some offset index property within it. For example: the `count` of the 
 String, is the offset index of the endIndex.The enumerated() generated a 
 sequence with elements contains the same offset as the offset index system 
 provided. And when we apply

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

2017-12-14 Thread Nicole Jacque via swift-evolution

Ok let’s keep it as is, and it is easy enough to add a new category if it 
appears to be useful.

> On Dec 14, 2017, at 10:14 AM, John McCall  wrote:
> 
>> On Dec 14, 2017, at 1:11 PM, Jon Shier > > wrote:
>> Personally I’d wait and see if much third party discussion happens and the 
>> split it out if it gets too noisy. Otherwise you’re separating discussions 
>> before we know they’ll happen. 
> 
> Yes, I've come around to this position, too.
> 
> John.
> 
>> 
>> On Dec 14, 2017, at 11:01 AM, John McCall via swift-evolution 
>> > wrote:
>> 
>>> 
 On Dec 14, 2017, at 1:38 AM, Nicole Jacque > wrote:
 
 Could you explain a bit more about how you think that category might be 
 used (vs. discussion) and organized?
>>> 
>>> Well, I was thinking it could be a place for people to form stable working 
>>> groups for various projects.  I suppose Development or Evolution is a more 
>>> appropriate category for that when the "library or open source project" is 
>>> the Swift project itself, so this would just be for other projects, and 
>>> maybe there isn't enough of a compelling need to split that out from Using 
>>> Swift.
>>> 
>>> John.
>>> 
 
> On Dec 13, 2017, at 9:58 PM, John McCall via swift-evolution 
> > wrote:
> 
>> On Dec 13, 2017, at 6:00 PM, Jonathan Hull via swift-evolution 
>> > wrote:
>> I would also like a place in the “Using Swift” for working on libraries 
>> or open source projects. I think asking for collaborators is 
>> fundamentally different than asking technical questions.
>> 
>> It would be nice to have support somehow for the idea of working groups 
>> for evolution
> 
> Having a Workspace category for project collaboration makes a lot of 
> sense to me.
> 
> John.
> 
>> 
>> 
>>> On Dec 12, 2017, at 3:31 AM, Alejandro Martinez via swift-evolution 
>>> > wrote:
>>> 
>>> This sounds great!
>>> Specially the new structure, it reminds me of the Rust forums. I just
>>> have one question, is the Using Swift category expected to be the one
>>> where the community posts project announcements for new libraries or
>>> similar stuff? I remember a recent thread where some people wanted to
>>> include more libs in the standard swift distribution and one of the
>>> alternatives considered was making it easy for the community to get
>>> together and share new projects and even join forces. This would seem
>>> like the perfect place for it, similar to the announcements category
>>> on Rust forum.
>>> 
>>> 
>>> On Tue, Dec 12, 2017 at 7:42 AM, Ben Rimmington via swift-evolution
>>> > wrote:
 [Forum] merging multiple staged accounts
 >
 
 [Forum] importing names with non-Latin characters
 >
 
 -- Ben
 
> On 12 Dec 2017, at 06:41, Ben Rimmington wrote:
> 
> When claiming a staged account, can the username be changed?
> e.g. Having the same "@username" on GitHub and Swift Forums.
> 
> Will people with multiple accounts be able to merge them?
>  >
> 
> Names with non-Latin characters are not imported correctly:
>  >
> e.g. StringTransform("Any-Latin; Latin-ASCII; Any-Title")
> 
> -- Ben
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> 
>>> 
>>> -- 
>>> Alejandro Martinez
>>> http://alejandromp.com 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

2017-12-14 Thread John McCall via swift-evolution

> On Dec 14, 2017, at 1:11 PM, Jon Shier  wrote:
> Personally I’d wait and see if much third party discussion happens and the 
> split it out if it gets too noisy. Otherwise you’re separating discussions 
> before we know they’ll happen. 

Yes, I've come around to this position, too.

John.

> 
> On Dec 14, 2017, at 11:01 AM, John McCall via swift-evolution 
> > wrote:
> 
>> 
>>> On Dec 14, 2017, at 1:38 AM, Nicole Jacque >> > wrote:
>>> 
>>> Could you explain a bit more about how you think that category might be 
>>> used (vs. discussion) and organized?
>> 
>> Well, I was thinking it could be a place for people to form stable working 
>> groups for various projects.  I suppose Development or Evolution is a more 
>> appropriate category for that when the "library or open source project" is 
>> the Swift project itself, so this would just be for other projects, and 
>> maybe there isn't enough of a compelling need to split that out from Using 
>> Swift.
>> 
>> John.
>> 
>>> 
 On Dec 13, 2017, at 9:58 PM, John McCall via swift-evolution 
 > wrote:
 
> On Dec 13, 2017, at 6:00 PM, Jonathan Hull via swift-evolution 
> > wrote:
> I would also like a place in the “Using Swift” for working on libraries 
> or open source projects. I think asking for collaborators is 
> fundamentally different than asking technical questions.
> 
> It would be nice to have support somehow for the idea of working groups 
> for evolution
 
 Having a Workspace category for project collaboration makes a lot of sense 
 to me.
 
 John.
 
> 
> 
>> On Dec 12, 2017, at 3:31 AM, Alejandro Martinez via swift-evolution 
>> > wrote:
>> 
>> This sounds great!
>> Specially the new structure, it reminds me of the Rust forums. I just
>> have one question, is the Using Swift category expected to be the one
>> where the community posts project announcements for new libraries or
>> similar stuff? I remember a recent thread where some people wanted to
>> include more libs in the standard swift distribution and one of the
>> alternatives considered was making it easy for the community to get
>> together and share new projects and even join forces. This would seem
>> like the perfect place for it, similar to the announcements category
>> on Rust forum.
>> 
>> 
>> On Tue, Dec 12, 2017 at 7:42 AM, Ben Rimmington via swift-evolution
>> > wrote:
>>> [Forum] merging multiple staged accounts
>>> >> >
>>> 
>>> [Forum] importing names with non-Latin characters
>>> >> >
>>> 
>>> -- Ben
>>> 
 On 12 Dec 2017, at 06:41, Ben Rimmington wrote:
 
 When claiming a staged account, can the username be changed?
 e.g. Having the same "@username" on GitHub and Swift Forums.
 
 Will people with multiple accounts be able to merge them?
 >
 
 Names with non-Latin characters are not imported correctly:
 >
 e.g. StringTransform("Any-Latin; Latin-ASCII; Any-Title")
 
 -- Ben
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 
>> 
>> -- 
>> Alejandro Martinez
>> http://alejandromp.com 
>> ___
>> 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

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

2017-12-14 Thread Jon Shier via swift-evolution

Personally I’d wait and see if much third party discussion happens and the 
split it out if it gets too noisy. Otherwise you’re separating discussions 
before we know they’ll happen. 

> On Dec 14, 2017, at 11:01 AM, John McCall via swift-evolution 
>  wrote:
> 
> 
>> On Dec 14, 2017, at 1:38 AM, Nicole Jacque  wrote:
>> 
>> Could you explain a bit more about how you think that category might be used 
>> (vs. discussion) and organized?
> 
> Well, I was thinking it could be a place for people to form stable working 
> groups for various projects.  I suppose Development or Evolution is a more 
> appropriate category for that when the "library or open source project" is 
> the Swift project itself, so this would just be for other projects, and maybe 
> there isn't enough of a compelling need to split that out from Using Swift.
> 
> John.
> 
>> 
 On Dec 13, 2017, at 9:58 PM, John McCall via swift-evolution 
  wrote:
 
 On Dec 13, 2017, at 6:00 PM, Jonathan Hull via swift-evolution 
  wrote:
 I would also like a place in the “Using Swift” for working on libraries or 
 open source projects. I think asking for collaborators is fundamentally 
 different than asking technical questions.
 
 It would be nice to have support somehow for the idea of working groups 
 for evolution
>>> 
>>> Having a Workspace category for project collaboration makes a lot of sense 
>>> to me.
>>> 
>>> John.
>>> 
 
 
> On Dec 12, 2017, at 3:31 AM, Alejandro Martinez via swift-evolution 
>  wrote:
> 
> This sounds great!
> Specially the new structure, it reminds me of the Rust forums. I just
> have one question, is the Using Swift category expected to be the one
> where the community posts project announcements for new libraries or
> similar stuff? I remember a recent thread where some people wanted to
> include more libs in the standard swift distribution and one of the
> alternatives considered was making it easy for the community to get
> together and share new projects and even join forces. This would seem
> like the perfect place for it, similar to the announcements category
> on Rust forum.
> 
> 
> On Tue, Dec 12, 2017 at 7:42 AM, Ben Rimmington via swift-evolution
>  wrote:
>> [Forum] merging multiple staged accounts
>> 
>> 
>> [Forum] importing names with non-Latin characters
>> 
>> 
>> -- Ben
>> 
>>> On 12 Dec 2017, at 06:41, Ben Rimmington wrote:
>>> 
>>> When claiming a staged account, can the username be changed?
>>> e.g. Having the same "@username" on GitHub and Swift Forums.
>>> 
>>> Will people with multiple accounts be able to merge them?
>>> 
>>> 
>>> Names with non-Latin characters are not imported correctly:
>>> 
>>> e.g. StringTransform("Any-Latin; Latin-ASCII; Any-Title")
>>> 
>>> -- Ben
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> -- 
> Alejandro Martinez
> http://alejandromp.com
> ___
> 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] constant var

2017-12-14 Thread Joe Groff via swift-evolution



> On Dec 14, 2017, at 12:51 AM, Inder Kumar Rathore .  
> wrote:
> 
> class MyClass {
>   private var myDict = [String : String]()
>   
>   func addMemebr() {
> self.myDict["key"] = "value" // Ok for me
>   }
>   
>   func anotherFunc() {
> self.myDict = [String : String]() // Not okay for me, I don't want any 
> code to do this within the class
>   }
> }

If you want code to be able to insert, but not delete from or otherwise freely 
change, the dictionary value, you could provide a wrapper type for myDict that 
provides a restricted mutation API:

struct InsertOnlyDictionary {
  private(set) var value = [String: String]()

  mutating func insert(_ k: String, _ v: String) {
value[k] = v
  }
}

// Code outside of InsertOnlyDictionary can read its `value`, but can only 
modify it by its `insert` API
class MyClass {
  private var myDict = InsertOnlyDictionary()

  func addMember() {
self.myDict.insert("key", "value")
  }
}

-Joe

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

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

2017-12-14 Thread John McCall via swift-evolution

> On Dec 14, 2017, at 1:38 AM, Nicole Jacque  wrote:
> 
> Could you explain a bit more about how you think that category might be used 
> (vs. discussion) and organized?

Well, I was thinking it could be a place for people to form stable working 
groups for various projects.  I suppose Development or Evolution is a more 
appropriate category for that when the "library or open source project" is the 
Swift project itself, so this would just be for other projects, and maybe there 
isn't enough of a compelling need to split that out from Using Swift.

John.

> 
>> On Dec 13, 2017, at 9:58 PM, John McCall via swift-evolution 
>> > wrote:
>> 
>>> On Dec 13, 2017, at 6:00 PM, Jonathan Hull via swift-evolution 
>>> > wrote:
>>> I would also like a place in the “Using Swift” for working on libraries or 
>>> open source projects. I think asking for collaborators is fundamentally 
>>> different than asking technical questions.
>>> 
>>> It would be nice to have support somehow for the idea of working groups for 
>>> evolution
>> 
>> Having a Workspace category for project collaboration makes a lot of sense 
>> to me.
>> 
>> John.
>> 
>>> 
>>> 
 On Dec 12, 2017, at 3:31 AM, Alejandro Martinez via swift-evolution 
 > wrote:

 This sounds great!
 Specially the new structure, it reminds me of the Rust forums. I just
 have one question, is the Using Swift category expected to be the one
 where the community posts project announcements for new libraries or
 similar stuff? I remember a recent thread where some people wanted to
 include more libs in the standard swift distribution and one of the
 alternatives considered was making it easy for the community to get
 together and share new projects and even join forces. This would seem
 like the perfect place for it, similar to the announcements category
 on Rust forum.

 On Tue, Dec 12, 2017 at 7:42 AM, Ben Rimmington via swift-evolution
 > wrote:
> [Forum] merging multiple staged accounts
>  >
> 
> [Forum] importing names with non-Latin characters
>  >
> 
> -- Ben
> 
>> On 12 Dec 2017, at 06:41, Ben Rimmington wrote:
>> 
>> When claiming a staged account, can the username be changed?
>> e.g. Having the same "@username" on GitHub and Swift Forums.
>> 
>> Will people with multiple accounts be able to merge them?
>> > >
>> 
>> Names with non-Latin characters are not imported correctly:
>> > >
>> e.g. StringTransform("Any-Latin; Latin-ASCII; Any-Title")
>> 
>> -- Ben
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution

 -- 
 Alejandro Martinez
 http://alejandromp.com 
 ___
 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] Optional Argument Chaining

2017-12-14 Thread Matthew Johnson via swift-evolution



Sent from my iPad

On Dec 13, 2017, at 11:13 PM, Stephen Celis  wrote:

>> On Dec 13, 2017, at 9:53 PM, Erica Sadun  wrote:
>> 
>> Chris L had a beautiful solution for an "Unwrappable" protocol that allowed 
>> all of the optional sugar to be extended to any type that had a biased 
>> `Wrapped` item, allowing it to be used with `Either`, `Wrapped`, etc as well 
>> as form the basis for `Optional` itself.
>> 
>> protocol Unwrappable {
>>  associatedtype Element
>>  func unwrap() -> Element?
>> }
> 
> It would definitely be nice to make "Optional" sugar work for non-"Optional" 
> types! (I think the goal for "async"/"await" is to make it work for any 
> continuation, so it's basically Haskell "do" notation for Swift!)
> 
> I'm not sure the "Unwrappable" protocol can handle many of the examples I 
> mentioned (accumulative errors, parallelism), though I wonder if it could be 
> designed differently to do so. The applicative structure requires just 2 
> functions[1]:
> 
>protocol Applicative: Functor {
>  static func pure(_ value: A) -> Self
>  static func <*> (lhs: Self<(A) -> B>, rhs: Self) -> Self 
>}
> 
> Such a protocol isn't possible in Swift (yet),

Thanks for jumping in and elaborating on a more general approach!  I don’t want 
to sidetrack the thread, but it actually is possible to encode higher-kindred 
types and protocols requiring them in Swift today.  It’s a bit clunky and 
requires some boilerplate but the technique is worth knowing.  
https://gist.github.com/anandabits/f12a77c49fc002cf68a5f1f62a0ac9c4

Some Kotlin folks have created a pretty robust FP library using the same 
technique: http://kategory.io/.

> but it could unlock this kind of sugar for everyone. Here's "Optional" 
> conformance:
> 
>extension Optional: Applicative {
>  static func pure(_ value: Wrapped) -> Wrapped? {
>return value // promoted to Optional.some
>  }
> 
>  static func <*> (lhs: Optional<(Wrapped) -> B>, rhs: Optional) -> B? {
>guard let lhs = lhs, rhs = rhs else { return nil }
>return lhs(rhs)
>  }
>}
> 
> We can't conform to such an "Applicative" protocol today, but we _can_ still 
> write and use these functions in a concrete manner! (Delete the conformance 
> and see!)
> 
> The original post in this thread had this example:
> 
>getPostageEstimate(source: String, destination: String, weight: Double)
> 
> If we were dealing with this function in the world of optional arguments, 
> here's how we could use our abstraction:
> 
>Optional.pure(curry(getPostageEstimate)) <*> john.address <*> 
> alice.address <*> pure(2.0)
> 
> It's not _too_ bad, though it's kinda noisy, we have to maintain a bunch of 
> custom code, we have to curry "getPostageEstimate" before passing it through, 
> we lose our argument labels, and we're living in custom operator world, which 
> can be disconcerting at first.
> 
> If Swift provided sugar over this structure, we'd merely need to do this:
> 
>getPostageEstimate(|source: john.address, destination: alice.address, 
> weight: 2.0|)
> 
> What's even neater is we can use this same format for types that wrap values 
> in other ways! Let's say the addresses are coming from untrusted sources and 
> need to be validated:
> 
>getPostageEstimate(|source: try validateAddr(john), destination: try 
> validateAddr(alice), weight: 2.0|)
> 
> If both addresses are invalid and "throw", we could get both errors and 
> render them at once to our end user.
> 
> Another example: what if we want to get the postage estimate for two 
> addresses that we need to fetch asynchronously:
> 
>getPostageEstimate(|source: await myAddress(), destination: await 
> theirAddress(), weight: 2.0|)
> 
> Such a syntax allows those requests to run in parallel and not block :)
> 
> In these examples, "Optional" promotion becomes applicative promotion ("2.0" 
> is getting wrapped automatically), which might open a can of worms but it's a 
> fun can to think about!
> 
> 
> --
> [1]: Well, technically it also requires "map", since any applicative is a 
> functor, and it also requires that it follows some math laws.
> 
> 
> Stephen
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] constant var

2017-12-14 Thread Magnus Ahltorp via swift-evolution


> 14 Dec. 2017 09:52 Inder Kumar Rathore . via swift-evolution 
>  wrote:
> 
> class MyClass {
>   private var myDict = [String : String]()
>   
>   func addMemebr() {
> self.myDict["key"] = "value" // Ok for me
>   }
>   
>   func anotherFunc() {
> self.myDict = [String : String]() // Not okay for me, I don't want any 
> code to do this within the class
>   }
> }

Let me take another example, if we write this extension to Int:

extension Int {
subscript(bit: Int) -> Bool {
get {
return get_bit_value(self, bit)
}
set {
   self = set_bit_value(self, bit, newValue)
}
}
}

this wouldn't be meaningful, right?

class MyClass {
  private var myInt : Int = 0
  
  func addMember() {
self.myInt[10] = true // Ok for me
  }
  
  func anotherFunc() {
self.myInt = 3 // Not okay for me, I don't want any code to do this within 
the class
  }
}

There is no conceptual difference between Dictionary and Int here.

/Magnus

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

Re: [swift-evolution] constant var

2017-12-14 Thread Nick Keets via swift-evolution

What are you going to do about this then?

func thirdFunc() {

self.myDict.removeAll()

}


Is this ok or not? Is it really different from `anotherFunc`?



On Thu, Dec 14, 2017 at 10:52 AM, Inder Kumar Rathore . via swift-evolution
 wrote:

> class MyClass {
>
>   private var myDict = [String : String]()
>
>
>
>   func addMemebr() {
>
> self.myDict["key"] = "value" // Ok for me
>
>   }
>
>
>
>   func anotherFunc() {
>
> self.myDict = [String : String]() // Not okay for me, I don't want
> any code to do this within the class
>
>   }
>
> }
>
> On Tue, Dec 12, 2017 at 10:28 PM, Joe Groff  wrote:
>
>>
>>
>> > On Dec 11, 2017, at 11:34 PM, Inder Kumar Rathore . via swift-evolution
>>  wrote:
>> >
>> > Hi All,
>> > Today I was writing code and faced a situation where I need to make a
>> instance variable a const i.e. it shouldn't accept new values from anywhere
>> but the problem is that I want it's content to be mutable.
>> >
>> > e.g.
>> >
>> > class MyClass {
>> >   var myDict = [String : String]()
>> > }
>>
>> You can do this by making the setter private:
>>
>> class MyClass {
>>   private(set) var myDict = [String: String]()
>> }
>>
>> This will allow declarations inside the MyClass definition to modify
>> myDict, but not code outside the class definition.
>>
>> -Joe
>>
>>
>
>
> --
> Best regards,
> Inder Kumar Rathore
>
> ___
> 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] constant var

2017-12-14 Thread Magnus Ahltorp via swift-evolution

> 14 Dec. 2017 17:52 Inder Kumar Rathore . via swift-evolution 
>  wrote:
> 
> class MyClass {
>   private var myDict = [String : String]()
>   
>   func addMemebr() {
> self.myDict["key"] = "value" // Ok for me
>   }
>   
>   func anotherFunc() {
> self.myDict = [String : String]() // Not okay for me, I don't want any 
> code to do this within the class
>   }
> }

But in Swift, since myDict is a Dictionary, it is *one* value, so it doesn't 
make sense to allow one but not the other. Also, since it is one value, you 
will not be able to detect the difference between setting a part of a 
dictionary and the whole dictionary. If Dictionary had been a class, there 
would be a non-changing reference, but there isn't in this case. Conceptually, 
the whole dictionary is copied every time you set it or assign it.

/Magnus

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

Re: [swift-evolution] constant var

2017-12-14 Thread Inder Kumar Rathore . via swift-evolution

class MyClass {

  private var myDict = [String : String]()



  func addMemebr() {

self.myDict["key"] = "value" // Ok for me

  }



  func anotherFunc() {

self.myDict = [String : String]() // Not okay for me, I don't want any
code to do this within the class

  }

}

On Tue, Dec 12, 2017 at 10:28 PM, Joe Groff  wrote:

>
>
> > On Dec 11, 2017, at 11:34 PM, Inder Kumar Rathore . via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hi All,
> > Today I was writing code and faced a situation where I need to make a
> instance variable a const i.e. it shouldn't accept new values from anywhere
> but the problem is that I want it's content to be mutable.
> >
> > e.g.
> >
> > class MyClass {
> >   var myDict = [String : String]()
> > }
>
> You can do this by making the setter private:
>
> class MyClass {
>   private(set) var myDict = [String: String]()
> }
>
> This will allow declarations inside the MyClass definition to modify
> myDict, but not code outside the class definition.
>
> -Joe
>
>


-- 
Best regards,
Inder Kumar Rathore
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

2017-12-14 Thread Pertti Kröger via swift-evolution

I do not feel new syntax is needed for this.
You can do this currently:

postfix operator ¿

extension Optional {
struct UnwrapError: Error {}
static postfix func ¿(_ value: Optional) throws -> Wrapped {
if let value = value {
return value
} else {
throw UnwrapError()
}
}
}

Given function f: (Foo, Foo, Foo) -> Void
and functions a, b, c: () -> Foo?
you would then chain the calls like

try? f(a()¿, b()¿, c()¿)

This is hardly more verbose than

f(a()?, b()?, c()?)

At least on mac keyboard ¿ is not hard to type either.
Also everyone is free to bikeshed the operator to their liking.

If special syntax were to be added for this, then in my opinion
the behaviour should mimic this; i.e. evaluate arguments left-to-right,
abort on first nil.

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

[swift-evolution] Discourse rollout re-schedule

Re: [swift-evolution] [swift-dev] Make offset index available for String

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

Re: [swift-evolution] constant var

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

Re: [swift-evolution] Optional Argument Chaining

Re: [swift-evolution] constant var

Re: [swift-evolution] constant var

Re: [swift-evolution] constant var

Re: [swift-evolution] constant var

Re: [swift-evolution] Optional Argument Chaining

13 matches

Site Navigation

Mail list logo

Footer information