Re: [swift-evolution] [Pitch] Move All Discussions To Github Issues

[Muse M via swift-evolution]

All of your points have been discussed and some of us will prefer Discourse
to generate mailing format. I remember there is an option for "Mailing List
mode" in Discourse.

You can trace from this discussion and there were a long separate threads
few months back which you can trace manually.
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031657.html

On Mon, May 1, 2017 at 8:40 PM, Mohamed Ebrahim Afifi via swift-evolution <
swift-evolution@swift.org> wrote:

> Thanks for your reply! I think that is very good news that the burden of
> the mailing list is so obvious for everyone!
>
> I think Github issues would be better though, the community is used to it
> and it makes more sense as it needs almost no configurations, no operation
> costs or maintenance. If the community decided to move to it we can move to
> it immediately, we don't need to wait. It is a natural next step since the
> proposals are maintained there and Swift itself is maintained there.
>
>
> Do you have a link to that discussion?
>
>
>
>
> Best Regards,
> Mohamed Afifi
>
> On Mon, May 1, 2017 at 1:33 PM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
>> Hi there,
>>
>> you’re a bit too late. A forum will come at some point (Discourse).
>>
>> Best regards,
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 1. Mai 2017 um 13:30:55, Mohamed Ebrahim Afifi via swift-evolution (
>> swift-evolution@swift.org) schrieb:
>>
>> Hi,
>>
>> This is actually not a proposal to improve Swift, it is actually a
>> proposal to improve the way we use it to improve Swift. :)
>>
>> It is extremely hard to monitor discussions going over e-mails.
>>
>>1. I always get lost between e-mails especially if there are so many
>>replies
>>2. It is extremely hard to reach the original idea/first e-mail.
>>3. New people (like me) usually get lost between e-mails and only
>>focus on their own idea and don't care about other's ideas because for
>>example, I don't know how to reply to an idea if I'm not subscribed to the
>>mailing list. In other words, It’s not a system that encourages follow-up
>>actions.
>>4. You can not browse subjects and all replies in one place.
>>5. You cannot follow a specific topic and ignore others.
>>
>> That was the problem!
>>
>> My suggestion is to move all discussions from this mailing list to GitHub
>> issues. For the following reasons.
>>
>>1. Easier to browse all topics.
>>2. You can see open topics and closed topics. So, if a topic is done
>>we can close it.
>>3. You can subscribe to a topic and follow all replies and reply.
>>4. Markdown support. Currently, I see people create a markdown page
>>on Github and send a link to it on the mailing list. But having the
>>markdown inline in the topic is a great benefit. Also, replies can be in
>>markdown as well.
>>5. It's closer to Proposals (Since we already using Github for
>>tracking proposals why don't we use it also to track pitching ideas).
>>People like to have everything gathered together in one place and don't
>>need to remember the Github repo and mailing list.
>>6. Github has https://developer.github.com/v3/issues/
>>
>>
>> I think using Github issues instead of the mailing lists will increase
>> the engagement of the Swift community with proposals.
>>
>>
>> Best Regards,
>> Mohamed Afifi
>> ___
>> 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] [Review] SE-0168: Multi-Line String Literals

[Muse M via swift-evolution]

This would be prefer to follow Scala multiline string which look

1) //Default
var code = """header
paragraph1"""

*Output:*
>header
>paragraph1

2)
var code = """
...header...
...paragraph1...
""".replace("...")

*Output:*
>header
>paragraph1

3)
var code = """
 |..header...
 |..paragraph1...
""".stripLeadingSpace()

*Output:*
>header...
>paragraph1...

4)
var code = """

import Foundation
print("Hello World!")

""".code()

*Output:*
>
>import Foundation
>print("Hello World!")
>

5)
//To remove all new lines
var code = """
import Foundation

import Cocoa

print("Hello World!")
""".compactLine()

*Output:*
>import Foundation
>import Cocoa
>print("Hello World!")



On Multiline String collection

6) If we are importing many sources from 3rd parties API, we won't know if
their code is properly indent, some use tab and some use 2 or 4-space. This
would look better on Swift Playground app.

var *stories* = {
"""
Chapter1
第1章

Introduction to A
""",
"""
Chapter2
第2章

Introduction to B
""",
"""
//Code Example
import Foundation
"""
}

We can loop or apply to certain collection
stories(3).code()



On Saturday, April 15, 2017, Ricardo Parada via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree that it is not obvious.
>
> At one point I argued that the trailing newline on the last line should be
> stripped. But for this reason and others I am now in the camp that thinks
> we should leave the trailing newline alone.
>
> If we don't want to include the trailing newline we can always do this:
>
> let str = """
>Line 1
>Line 2\
>"""
>
> This is were it's difficult to get consensus.
>
> Regards,
> Ricardo
>
>
> On Apr 14, 2017, at 5:54 PM, BJ Homer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’m not saying that the + operator should automatically add a newline. I’m
> saying that both strings should contain a trailing newline, such that the
> visible result is the same.
>
> By contrast, this would feel really strange:
>
> let a = """
> This is line one
> This is line two
>
>
> """
>
>
> let b = """
> This is line three
> This is line four
>
> """
>
>
> (a + b) == """
> This is line one
> This is line two
> This is line three
> This is line four
> """
>
>
> On initial intuition, it seems strange that ‘a’ has a blatantly visible
> blank line at the end which seemingly “disappears” when the strings are
> concatenated. If I think about it for a bit, I can understand why that
> would be the case, but I think it’s non-obvious.
>
> -BJ
>
> On Apr 14, 2017, at 3:49 PM, Xiaodi Wu  wrote:
>
> I disagree. I expect the last result to be from `a + "\n" + b`, for the
> reasons I outlined earlier.
>
> The concatenation operator + does not introduce implied separators when
> joining strings. There is no reason to think that it should for multi-line
> strings specifically.
> On Fri, Apr 14, 2017 at 16:35 BJ Homer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> Consider these two examples:
>>
>> let string_1 = """foo"""
>>
>>
>> let string_2 = """
>> foo
>> """
>>
>> What’s the intuitive result you’d expect without taking all the long talk
>> from the list into account?
>>
>> Personally, I’d say string_1 == string_2 is true.
>>
>>
>> I think it’s reasonable to expect them to be different, actually. I might
>> call these “single-line” and “multi-line” mode strings. The single-line
>> mode is primarily useful for being able to include unescaped double-quotes
>> in the string. If you’re in multi-line mode, though, it’s reasonable to be
>> thinking about things in terms of “lines”, and having a trailing newline
>> there seems reasonable. For example, I think it’s reasonable to expect this:
>>
>> let a = """
>> This is line one
>> This is line two"
>> """
>>
>> let b = """
>> This is line three
>> This is line four
>> """
>>
>> (a + b) == """
>> This is line one
>> This is line two
>> This is line three
>> This is line four
>> """
>>
>>
>> That seems like a reasonable model to work with multi-line strings.
>>
>> -BJ
>> ___
>> 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] [Review] SE-0168: Multi-Line String Literals

[Muse M via swift-evolution]

In Javascript, this counted as 2 lines which is fine for rendering code,
not with HTML5 elements
import Foundation
print("Hello World!")

1st)
In Swift, it's clear to start multi-line on a new line
var code =
*"""*
Hello World
*"""*

If Swift cannot accept the 1st syntax, below 2nd and 3rd syntax could be
done better
2nd)
*var code = """*
Hello World
*"""*

3)
*var code = {*
*"""*
Hello World
*"""*
}

I love the 3rd syntax.



On Fri, Apr 14, 2017 at 5:06 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> I think I found another argument of not to inject a new line after the
> last content line, even though it’s not a strong argument.
>
> Consider these two examples:
>
> let string_1 = """foo"""
>
>
> let string_2 = """
> foo
> """
>
> What’s the intuitive result you’d expect without taking all the long talk
> from the list into account?
>
> Personally, I’d say string_1 == string_2 is true.
>
> Now you’d might think how about the blank line as an example?
>
> let string_3 = """
>
> """
>
> However the equivalent for this would be:
>
> let string_4 = """\n"""
>
> Empty string in both variations:
>
> let string_5 = ""
>
>
> let string_6 = """
> """
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 14. April 2017 um 03:08:58, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>
> On Thu, Apr 13, 2017 at 7:55 PM, Brent Royal-Gordon <
> br...@architechies.com> wrote:
>
>> On Apr 13, 2017, at 4:48 PM, Xiaodi Wu  wrote:
>>
>> You say "this is the example set by `print`", but I don't think anything
>>> else actually *follows* that example. No other I/O operation in Swift
>>> behaves this way.
>>>
>>
>> To be more accurate, it's not `print` that specifies this behavior, but
>> rather the standard output stream's implementation of
>> `TextOutputStream.write(_:)`. Swift *explicitly* leaves this choice up to
>> the TextOutputStream-conforming type. That is, the behavior is up to the
>> receiver and not the argument of a call to `TextOutputStream.write(_:)`.
>>
>>
>> I feel like I must be misunderstanding what you're trying to say here,
>> because I *think* what you're trying to say is that
>> `TextOutputStream.write(_:)` is what decides whether to add the terminator,
>> which is not only totally wrong (see https://github.com/apple/
>> swift/blob/adc54c8a4d13fbebfeb68244bac401ef2528d6d0/stdlib/
>> public/core/Print.swift#L260) but doesn't even make any sense since
>> there's a terminator parameter on `print` but none on `write(_:)`.
>>
>
> Hmm, you're right here with respect to `print()`. It is, however,
> explicitly contemplated in the documentation for
> `TextOutputStream.write(_:)` that conforming types can also determine
> whether or not to append a terminator, and which, inside their
> implementation of `write`. The example given in the documentation is:
>
> ```
> struct ASCIILogger: TextOutputStream {
> mutating func write(_ string: String) {
> let ascii = string.unicodeScalars.lazy.map { scalar in
> scalar == "\n"
>   ? "\n"
>   : scalar.escaped(asASCII: true)
> }
> print(ascii.joined(separator: ""), terminator: "")
> }
> }
> ```
>
>
>
>> --
>> 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] Add an all algorithm to Sequence

[Muse M via swift-evolution]

In additional, containsAll(value: "123") is prefer and more natural as we
speak.


On Thursday, April 6, 2017, Muse M  wrote:

> I accept "contains" for at least match one result, similar to OR.
> "containsOnly" is similar to AND for one element or more elements must
> contain same values and types.
>
> On Thursday, April 6, 2017, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
>> In JavaScipt they are known as "every" and "includes".
>>
>> In C# they are "TrueForAll" and "Exists".
>>
>> Not sure why "all" and "contains" is any less consistent.
>> On Thu, Apr 6, 2017 at 05:50 Víctor Pimentel Rodríguez via
>> swift-evolution  wrote:
>>
>>> On Thu, Apr 6, 2017 at 12:44 AM, Jonathan Hull via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 On that note: ‘containsOnly' is still my favorite by a wide margin.  I
 know it is longer than ‘all’, but it’s behavior is much clearer (especially
 for those of us who have never used or heard of ‘all’ in other languages),
 and it’s relationship with ‘contains’ is also very clear.

>>>
>>> Also +1 to containsOnly for this very reason.
>>>
>>> In other languages (Python, Ruby, etc) that have an `all` method, they
>>> also have an `any` method, thus maintaining certain consistency.
>>>
>>> In the Swift standard library that `any` method is called `contains`, so
>>> `containsOnly` matches nicely that consistency.
>>>
>>> --
>>> Víctor Pimentel
>>> ___
>>> 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] Add an all algorithm to Sequence

[Muse M via swift-evolution]

I accept "contains" for at least match one result, similar to OR.
"containsOnly" is similar to AND for one element or more elements must
contain same values and types.

On Thursday, April 6, 2017, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> In JavaScipt they are known as "every" and "includes".
>
> In C# they are "TrueForAll" and "Exists".
>
> Not sure why "all" and "contains" is any less consistent.
> On Thu, Apr 6, 2017 at 05:50 Víctor Pimentel Rodríguez via swift-evolution
>  > wrote:
>
>> On Thu, Apr 6, 2017 at 12:44 AM, Jonathan Hull via swift-evolution <
>> swift-evolution@swift.org
>> > wrote:
>>
>>> On that note: ‘containsOnly' is still my favorite by a wide margin.  I
>>> know it is longer than ‘all’, but it’s behavior is much clearer (especially
>>> for those of us who have never used or heard of ‘all’ in other languages),
>>> and it’s relationship with ‘contains’ is also very clear.
>>>
>>
>> Also +1 to containsOnly for this very reason.
>>
>> In other languages (Python, Ruby, etc) that have an `all` method, they
>> also have an `any` method, thus maintaining certain consistency.
>>
>> In the Swift standard library that `any` method is called `contains`, so
>> `containsOnly` matches nicely that consistency.
>>
>> --
>> Víctor Pimentel
>> ___
>> 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] Add an all algorithm to Sequence

[Muse M via swift-evolution]

At this stage, it's rather confuse to me, if return boolean, probably
sizeOf and boolOf is easier for me.

boolOf(equalTo:)
boolOf(matching:)

On Sat, Apr 1, 2017 at 10:54 PM, Rien via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 01 Apr 2017, at 16:10, David Hart  wrote:
> >
> >>
> >> On 1 Apr 2017, at 11:32, Rien  wrote:
> >>
> >>
> >>> On 01 Apr 2017, at 10:47, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> On Sat, Apr 1, 2017 at 3:40 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
>  On 1 Apr 2017, at 09:50, Brandon Trussell 
> wrote:
> 
>  I agree that based on the method name, I thought a collection would
> be returned.
> >>>
> >>> Now that I think more about it, I think you're right. It is confusing.
> Perhaps:
> >>>
> >>> allAre(equalTo: )
> >>> allAre(matching: )
> >>>
> >>> Well, if we're going to go full stdlib naming guidelines, shouldn't
> they be--
> >>>
> >>> ```
> >>> areAll(equalTo:)
> >>> areAll(matching:)
> >>> ```
> >>
> >>
> >> thatAre(equalTo: )
> >> thatAre(matching: )
> >
> > That would be confusing again. You'd get the impression that the
> functions are returning elements of the Sequence, not a Bool.
>
> Yup. my bad.
>
> Rien.
>
>
> >
> >> Regards,
> >> Rien
> >>
> >> Site: http://balancingrock.nl
> >> Blog: http://swiftrien.blogspot.com
> >> Github: http://github.com/Balancingrock
> >> Project: http://swiftfire.nl
> >>
> >>
> >>>
>  On Sat, Apr 1, 2017 at 12:36 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
> 
> > On 1 Apr 2017, at 06:02, Will Stanton via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > +1 to adding, but the name `all` suggests (to me) the return of
> another sequence, not a Bool.
> 
>  I'm not too concerned because the mandatory labels makes it clear.
> 
> > Perhaps the function name should be question-like?
> >
> > Suggesting: `membersSatisfy(condition:)` or `allSatisfy(condition:)`
> or maybe even just `satisfies(condition:)`
> > The question-like modifier/verb is necessary to suggest a Bool and
> IMO not a needless word.
> >
> > Regards,
> > Will Stanton
> >
> >> On Mar 31, 2017, at 11:28, Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Hopefully non-controversial, aside from the naming of the method
> and arguments, about which controversy abounds
> >
> > ___
> > 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
> 
> 
> 
>  --
>  Brandon
> >>>
> >>> ___
> >>> 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] Smart KeyPaths

[Muse M via swift-evolution]

I would suggest a keypath using ~ which is concise and clearer to identify.

let myPath = Person~friends[0].name





On Sunday, March 19, 2017, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> This looks fantastic!
>
> The one worry I would have, as others have brought up, is confusion when
> there are static properties with the same name.  Maybe we could have a
> special static property called ‘keyPath’ or ‘path’ that would be reserved,
> and anything that followed would be a key path.
>
> So instead of:
>
> let myPath = Person.friends[0].name
>
> you would have:
>
> let myPath = Person.keyPath.friends[0].name
>
>
> Or if we want to choose a sentinel, I would nominate ‘$’:
>
> let myPath = $Person.friends[0].name
>
> Thanks,
> Jon
>
>
> On Mar 17, 2017, at 10:04 AM, Michael LeHew via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
> Hi friendly swift-evolution folks,
>
> The Foundation and Swift team  would like for you to consider the
> following proposal:
>
> Many thanks,
> -Michael
>
> Smart KeyPaths: Better Key-Value Coding for Swift
>
>- Proposal: SE-
>- Authors: David Smith , Michael LeHew
>, Joe Groff 
>- Review Manager: TBD
>- Status: *Awaiting Review*
>- Associated PRs:
>   - #644 
>
> Introduction
>
> We propose a family of concrete *Key Path* types that represent uninvoked
> references to properties that can be composed to form paths through many
> values and directly get/set their underlying values.
> MotivationWe Can Do Better than String
>
> On Darwin platforms Swift's existing #keyPath() syntax provides a
> convenient way to safely *refer* to properties. Unfortunately, once
> validated, the expression becomes a String which has a number of
> important limitations:
>
>- Loss of type information (requiring awkward Any APIs)
>- Unnecessarily slow to parse
>- Only applicable to NSObjects
>- Limited to Darwin platforms
>
> Use/Mention Distinctions
>
> While methods can be referred to without invoking them (let x = foo.bar 
> instead
> of  let x = foo.bar()), this is not currently possible for properties and
> subscripts.
>
> Making indirect references to a properties' concrete types also lets us
> expose metadata about the property, and in the future additional behaviors.
> More Expressive KeyPaths
>
> We would also like to support being able to use *Key Paths* to access
> into collections, which is not currently possible.
> Proposed solution
>
> We propose introducing a new expression akin to Type.method, but for
> properties and subscripts. These property reference expressions produce
> KeyPath objects, rather than Strings. KeyPaths are a family of generic
> classes *(structs and protocols here would be ideal, but requires
> generalized existentials)* which encapsulate a property reference or
> chain of property references, including the type, mutability, property
> name(s), and ability to set/get values.
>
> Here's a sample of it in use:
> Swift
>
> struct Person {
> var name: String
> var friends: [Person]
> var bestFriend: Person?}
> var han = Person(name: "Han Solo", friends: [])var luke = Person(name: "Luke 
> Skywalker", friends: [han])
> let firstFriendsNameKeyPath = Person.friends[0].name
> let firstFriend = luke[path] // han
> // or equivalently, with type inferred from contextlet firstFriendName = 
> luke[.friends[0].name]
> // rename Luke's first friend
> luke[firstFriendsNameKeyPath] = "A Disreputable Smuggler"
> let bestFriendsName = luke[.bestFriend]?.name  // nil, if he is the last jedi
>
> Detailed designCore KeyPath Types
>
> KeyPaths are a hierarchy of progressively more specific classes, based on
> whether we have prior knowledge of the path through the object graph we
> wish to traverse.
> Unknown Path / Unknown Root Type
>
> AnyKeyPath is fully type-erased, referring to 'any route' through an
> object/value graph for 'any root'. Because of type-erasure many operations
> can fail at runtime and are thus nillable.
> Swift
>
> class AnyKeyPath: CustomDebugStringConvertible, Hashable {
> // MARK - Composition
> // Returns nil if path.rootType != self.valueType
> func appending(path: AnyKeyPath) -> AnyKeyPath?
>
> // MARK - Runtime Information
> class var rootType: Any.Type
> class var valueType: Any.Type
>
> static func == (lhs: AnyKeyPath, rhs: AnyKeyPath) -> Bool
> var hashValue: Int}
>
> Unknown Path / Known Root Type
>
> If we know a little more type information (what kind of thing the key path
> is relative to), then we can use PartialKeyPath , which refers to
> an 'any route' from a known root:
> Swift
>
> class PartialKeyPath: AnyKeyPath {
> // MARK - Composition
> // Returns nil if Value != self.valueType
> func appending(path: 

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Muse M via swift-evolution]

I don't see any discussions to have Swift Server Side shift to Discourse
forum too?

On Thursday, February 9, 2017, James Hillhouse via swift-evolution <
swift-evolution@swift.org> wrote:

> I'll echo Nick and Joshua–thanks Swift Core team for taking the time to
> decide on this change.
>
> Jim
>
>
> > On Feb 8, 2017, at 9:37 PM, Rick Mann via swift-evolution <
> swift-evolution@swift.org > wrote:
> >
> > I second this praise. FWIW, I recently installed Discourse using a
> DigitalOcean droplet, and it couldn't have been easier. Upgrades are
> surprisingly easy, too.
> >
> > I have yet to figure out the email integration; I hope you can get that
> working.
> >
> > I also hope you give some effort to improving on the default Discourse
> look. It's not bad, but I feel like it doesn't do a good job of delineating
> functional areas on the page. Having said that, I'm more than happy to wait
> indefinitely for such an improvement; it's not worth holding up the
> roll-out.
> >
> > Thanks again!
> >
> >> On Feb 8, 2017, at 19:34 , Joshua Alvarado via swift-evolution <
> swift-evolution@swift.org > wrote:
> >>
> >> 
> >> This is an awesome decision and a huge enhancement for the Swift
> community. Thanks (Core Team) for taking the time to entertain the
> discussion and move forward with what many community members have wanted.
> >>
> >> Alvarado, Joshua
> >>
> >>> On Feb 8, 2017, at 5:03 PM, Ted kremenek via swift-evolution <
> swift-evolution@swift.org > wrote:
> >>>
> >>> Hi everyone,
> >>>
> >>> There was a long thread on swift-evolution about whether we should use
> modern forum software — like Discourse — as an alternative to the mailing
> lists we have now.  After a long discussion, the Core Team has decided to
> move swift-evolution and swift-users to Discourse.
> >>>
> >>> There are tradeoffs to moving to a forum.  The main advantages are:
> >>>
> >>> - Easy for people to participate without subscribing to the entire
> mailing list, as well as no need to provide email address to participate.
> A lot of people have voiced concern that they feel resistance to
> participate because of needing to subscribe to a mailing list.
> >>>
> >>> - Consistent affordances and rendering of content, including Markdown
> support.  This is really useful for having technical discussions.
> >>>
> >>> - Better searching of topics, archiving, etc.
> >>>
> >>> - More tools for moderation.
> >>>
> >>> - Topic cross-referencing, and consistent organization of topics
> instead of whatever threading support a mail client provides (which is
> inconsistent).
> >>>
> >>> I also want to consider moving the -dev lists to the same forum setup
> as well; but that will be a separate conversation on those lists.
> >>>
> >>> A rollout plan has not been figured out.  People are busy and there
> are logistics to figure out.  I will be engaging a handful of members from
> the community to help with the transition.  Specifically, there are those
> who really value using email for participation on swift-evolution and
> swift-users, and the goal is to get the forum setup to allow those people
> to continue to feel effective when using email for discussions on these
> "lists".
> >>>
> >>> More details will be announced as they get figured out, but I felt it
> was important to let the community know about this direction.
> >>>
> >>> Ted
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
> >
> >
> > --
> > Rick Mann
> > rm...@latencyzero.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

Re: [swift-evolution] [Discussion] mailing list alternative

[Muse M via swift-evolution]

One feature is I need the ability to bookmark where I stop reading
during the journey or trip.

A few contributors keep replying with quoted message ate up my mobile data
usage significantly especially this thread is getting a long discussion is
hard to read on a small screen and I don't use email clients on iPhone.

Forum is useful when we need share photos and video.


On Friday, February 3, 2017, Muse M  wrote:

> One feature is I need the ability to bookmark where I stop reading
> during the journey or trip.
>
> A few contributors keep replying with quoted message ate up my mobile data
> usage significantly especially this thread is getting a long discussion is
> hard to read on a small screen and I don't use email clients on iPhone.
>
> Forum is useful when we need share photos and video.
>
> On Friday, February 3, 2017, Tino Heth via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
>>
>> In a mailing list format, everyone is free to start a new thread.
>>
>> Would a forum have a privilege system that stops newbies from starting
>> threads? I've seen no one proposing that.
>>
>>
>> Whether you invented the language or started learning it yesterday, if
>> you have a new idea, it comes into everyone's inbox in exactly the same
>> way. No one's user name has extra flares or trophies or whatever reminding
>> you of their status.
>>
>>
>> Imho that's just wrong, and this message somewhat proves my point:
>> There are several users with a "@apple.com" trophy, and I guess most
>> people who spend a significant amount of time on swift-evolution also have
>> developed a preference not only for topics, but also for authors (saving
>> matching posts from being ignored).
>>
>> The ability to "like" posts would be a remarkable help for newbies to
>> gather attention for their ideas — not because of the status of the author,
>> but because of the quality of their contribution.
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Update on the Swift Project Lead

[Muse M via swift-evolution]

Tesla cars is now type-safe.

On Thu, Jan 12, 2017 at 3:21 AM, Derrick Ho via swift-evolution <
swift-evolution@swift.org> wrote:

> Have fun working at Tesla Mr Chris Lattner!
>
> I look forward to seeing tesla car apps that can be written in swift.
>
> On Wed, Jan 11, 2017 at 1:22 PM Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On 11 Jan 2017, at 18:18, John Pratt via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >
>> > You are just going to drop this entire project, that has its name
>> associated with you,
>> > for a very fierce competitor?
>> >
>>
>> That’s pretty insulting to everybody else who works on the project
>> (including the many contributors here).
>>
>> Besides, it’s just plain wrong. Swift is a tool, and like any other tool
>> it is judged on its intrinsic merit for a job, regardless of whichever
>> names may be attached to it.
>>
>> > However capable Ted Kremenek is, and I am sure that is, you have
>> collectively decided
>> > to break this programming language every year or so.
>> >
>> > Who is going to get behind this programming language now that it is
>> associated with
>> > a turncoat?
>>
>> We have contributors from IBM, Microsoft, Uber and/or Lyft, maybe also
>> from Facebook (not sure), Apple (obviously), and probably more. I don’t
>> think they all decided to invest time in making Swift better because Chris
>> Lattner told them he would always work at Apple. So chill.
>>
>> > ___
>> > 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] guard let x = x

[Muse M via swift-evolution]

In Rust lang, it uses .unwrap and b can be a non-nil variable.

guard a.unwrap, b, c.unwrap else {
}

On Tuesday, November 1, 2016, Nicholas Maccharoli via swift-evolution <
swift-evolution@swift.org> wrote:

> I like the idea of drying up something like `guard let x = x, let y = y,
> let z = z else { return }`
> Using `guard unwrap` would surely be an improvement but still maybe
> something like `guard unwrap x, unwrap y, unwrap x else { return }`
> although very clear in intent is a bit bulky.
>
> What about something like introducing a `given` / `given-where` clause for
> `if` and `guard` ensuring an optional  is non-nil and shadowing the
> variable with an unwrapped variable of the same name.
>
> one way might be:
>
> guard given a, b, c else { return }
>
> or with an attached conditional:
>
> guard given a, b, c where a > b else { return }
>
> for dealing with long if-lets you could do something like:
>
> if given a, b, c where a > b { ... }
>
> Instead of if let a = a, b = b, c = c, a > b { ... }
>
> The `where` clause does not need to be an actual keyword, it can just be a
> trailing boolean expression but
> maybe having it makes things like unwrapping and testing that a variable
> evaluates to `true` more distinguishable.
>
> something like `if given a, b, c, c { ... }` looks like it could be an
> accidental typed repeat of `a` as much as it could mean `if given a, b, c,
> c == true { ... }`
>
> `if given a, b, c where c { ... }` might read a little easier.
>
> Just a thought.
>
> - Nick
>
>
>
>
>
> On Tue, Nov 1, 2016 at 4:26 PM, Goffredo Marocchi via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
>> Agreed, a change like this would make sense :).
>>
>> Sent from my iPhone
>>
>> > On 1 Nov 2016, at 01:58, Joe Groff via swift-evolution <
>> swift-evolution@swift.org
>> > wrote:
>> >
>> >
>> >> On Oct 31, 2016, at 6:46 PM, Xiaodi Wu > > wrote:
>> >>
>> >> On Mon, Oct 31, 2016 at 8:37 PM, Joe Groff via swift-evolution <
>> swift-evolution@swift.org
>> > wrote:
>> >> Sorry for piling onto the bikeshed. We do already have a notation for
>> testing that an Optional isn't nil, `x != nil`. We could theoretically
>> bless ` != nil` as a statement condition to also unwrap the
>> referenced declaration in the scope guarded by the condition. (`
>> is T` could similarly rebind a declaration as the cast type.)
>> >>
>> >> I think we'd have some weirdness. For instance:
>> >>
>> >> ```
>> >> guard x != nil || x == y else { break }
>> >> // oops, now x isn't unwrapped anymore because I added a condition
>> >> ```
>> >>
>> >> Also, it'd be unexpected for it to be blessed for guard but not if:
>> >>
>> >> ```
>> >> if x != nil {
>> >>  // is x unwrapped here?
>> >>  // if so, this would be source-breaking...
>> >>  // if not, it would be surprisingly inconsistent
>> >> }
>> >> ```
>> >
>> > `if` and `guard` share the same condition behavior. It's true that
>> there would be limitations on when the unwrapping behavior applies, but QoI
>> could potentially help. Users seem to be able to work within similar
>> constraints in gradually-typed languages like Typescript that work
>> similarly, and there's quite a lot of Swift users who are surprised at
>> first that Swift doesn't behave similarly.
>> >
>> > -Joe
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> 
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Muse M via swift-evolution]

I would rather consider using a new keyword that could make it clearer
without looking up for description.

NewCurrent
moduleprivate over internal



On Sat, Oct 8, 2016 at 2:44 PM, Rien via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for me.
>
> I see a little benefit for teams that have multiple people working on a
> single file (not necessarily at the same time) where a case can be made for
> a distinction between fileprivate and private. Other than that there is imo
> no benefit. So to me the question is “is the benefit to those teams worth
> the burden on the rest of us”?
>
> I honestly do not know the answer to that.
>
> Personally I come down on the side of reverting this change.
>
> Btw: I was not present during the original discussion. If I had been I
> would have tried to make a case for a “friends list”. In which each scope
> could have a list of “friends” that have “private” access. This has the
> advantage that all external access to the scope would be documentation in
> that scope, and it would open up the possibility of granting private access
> to closures outside the file the scope was defined in. (private would then
> become class-private and fileprivate could be eliminated)
>
> Rien.
>
> > On 07 Oct 2016, at 23:44, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I actually feel exactly the opposite of this—personally I thought
> `private` was fine the way it was when it meant `fileprivate` and I had no
> real need for `private` as it exists in Swift 3.
> >
> > `fileprivate` is useful because it lets me organize my code in such a
> way that I divide large types (for example, those that conform to many
> delegates/other protocols) into multiple extensions in the same file. Any
> state or helpers that I want to keep in the main class can be defined as
> `fileprivate` and still be accessible throughout that file, without leaking
> them into the rest of my module if they were defined as `internal`.
> >
> > On the other hand, `private` would mostly just protect me from myself at
> a very small level. In all the Swift code that I've written (this is my
> anecdotal experience, of course, and I know others differ), it's rare that
> I've found a strong reason to or benefit from locking something down as
> `private` instead of `fileprivate`.
> >
> > Of course, one could argue that `fileprivate` is also protecting me from
> myself, just a file-based level instead of a scope-based level, but I think
> it would be more harmful to encourage leaking abstractions out of a file
> and into a module than it would to leak them out of a scope and into a
> single file. The affected surface area is much smaller in the latter case.
> >
> > One possible compromise that pops into my head would be to let `private`
> not apply to a scope but to a type and also to only those extensions on
> that type that are visible in the same file—that may have already been
> discussed during the review of the original proposal. I don't know what the
> complexity of it would be.
> >
> > Either way, I would be strongly against anything that removes
> `fileprivate`. I don't find much use for `private` and nobody is forcing me
> to use it, so I don't. On the other hand, removing `fileprivate` would
> prevent a design and code organization pattern that I enjoy about Swift.
> >
> >
> >
> > On Fri, Oct 7, 2016 at 2:06 PM Zach Waldowski via swift-evolution <
> swift-evolution@swift.org> wrote:
> > I third this sentiment. fileprivate is a nice idea and very clearly has
> its uses (which is why the proposal got traction in the first place), but
> when combined with the other access levels, the language feature as a whole
> feels arbitrary. In practical use, files that I felt were nicely
> encapsulated and hiding implementation details are now a scattered mix of
> access levels, adding cognitive load and making the code look unorganized
> for having the gall to use extensions to split up functionality.
> >
> > Sincerely,
> >   Zachary Waldowski
> >   z...@waldowski.me
> >
> >
> > On Fri, Oct 7, 2016, at 01:55 PM, Russ Bishop via swift-evolution wrote:
> >>
> >>> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I started the topic, but I also believe like you that the fileprivate
> vs private(file) discussion has already been thoroughly discussed and
> nothing new has been brought up. That’s not what I want to discuss.
> >>>
> >>> I instead want to share my experience using private and fileprivate
> since release. Here are my thoughts:
> >>>
> >>> • We should start with the premise that the proposal has added a
> substantial amount of complexity:
> >>> • It has added an extra modifier and access level to learn.
> >>> • It has complicated the access level rules with Inner
> types as mentioned in the Complications with private types section of the
> proposal.
> >>> • I have 

Re: [swift-evolution] More fine tuning optimization to swift compiler

[Muse M via swift-evolution]

-Oloop
Correction: it should be similar to GCC -funroll-loops
On other option if we have 1,000,000's loops or array, it's bad for one
core to handle 100% of the calculations and other cores are idle, the idea
could be optimize loops to share/split workload across all available CPU
cores.

-Ofunction
Is a dummy example for other example.

On Tue, Aug 9, 2016 at 11:21 PM, Félix Cloutier <felix...@yahoo.ca> wrote:

> My understanding is that -Ounchecked removes integer overflow checks and
> array bound checks.
>
> What type of optimizations would -Oloop and -Ofunction do?
>
> Félix
>
> Le 7 août 2016 à 19:27:56, Muse M via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I'm not sure if this is the right channel to discuss on optimization switch
>
> We are aware the 3 options:
> -O
> -Ofast
> -Ounchecked
>
> As we can see, we rarely use -Ounchecked for safety reason and there
> aren't much info on what are the tradeoff. if there are performance reason
> that will need to improve loop or maths optimization or allow developers to
> fine-tuning in various area, we could add more options to compiler.
>
> -OLoop (Optimize loop with safety)
> -OFunc (Optimize function calls)
> and so on.
>
>
>
> ___
> 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] More fine tuning optimization to swift compiler

[Muse M via swift-evolution]

I'm not sure if this is the right channel to discuss on optimization switch

We are aware the 3 options:
-O
-Ofast
-Ounchecked

As we can see, we rarely use -Ounchecked for safety reason and there aren't
much info on what are the tradeoff. if there are performance reason that
will need to improve loop or maths optimization or allow developers to
fine-tuning in various area, we could add more options to compiler.

-OLoop (Optimize loop with safety)
-OFunc (Optimize function calls)
and so on.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Muse M via swift-evolution]

Apple's developer forums need to rewrite in Swift.

On Fri, Aug 5, 2016 at 2:42 AM, Shawn Erickson via swift-evolution <
swift-evolution@swift.org> wrote:

> I concur on the general weakness of Apple's developer forums as they
> currently exist.
>
> On Thu, Aug 4, 2016 at 11:23 AM Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Just wanted to point out that Apple’s forum software is pretty terrible,
>> even after two (apparent) rewrites. It’s buggy, navigates differently from
>> other forum software, doesn’t render code inline very well, and it doesn’t
>> offer the integrations that Discourse does.
>>
>>
>>
>> Jon
>>
>> On Aug 3, 2016, at 7:52 PM, Charles Srstka via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Aug 3, 2016, at 4:11 PM, David Owens II via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> But does it already surpass the limits?
>>
>> • There is a bandwidth limit of 100k monthly page views, equivalent to
>> our Standard hosting plan.
>> • If you exceed our bandwidth limit – which is very unlikely, unless your
>> project is enormous – you have two options:
>> • We’ll help you move to self-hosting, either on your own server or any
>> Docker compatible cloud (a $20/month Digital Ocean droplet should suffice).
>> • Upgrade to our Business hosting plan at 50% off.
>>
>>
>> I wouldn’t be surprised if it’s close if not passed 100k monthly views
>> already.
>>
>> The big unknown is also around the mailing list support. Is it super
>> robust and work as well for communicating as the mailing currently does? I
>> don’t know. I’ve not been involved with large projects on discourse.
>>
>>
>> Apple has a lot of money; I doubt being unable to go with the free option
>> would be a big dealbreaker.
>>
>> It should probably be mentioned, though, that Apple already has a
>> developer forum set up, and a server to run it on, and everything. Is there
>> any reason they couldn’t just use that?
>>
>> Charles
>>
>> ___
>> 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] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Muse M via swift-evolution]

If Swift team have no roadmap on those plans, any swift developers with
strong in each area could kickstart and contributing libraries in Github
repo. We will greatly benefit from those areas and AI.

On Wed, Aug 3, 2016 at 11:10 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, Aug 3, 2016 at 9:48 AM, Nevin Brackett-Rozinsky via
> swift-evolution  wrote:
>
>> A few things immediately spring to mind:
>> • Fixed-size arrays
>> • An optimized Matrix type
>> • Swifty syntax for Fourier transforms
>> • A numerical integrator (or diff-eq solver!)
>> • BigInt capabilities
>>
>> The first of these (fixed-size arrays) will probably require compiler
>> support.
>>
>> The rest can already be done in a library, except I believe they will hit
>> the “generics cannot be specialized across module boundaries” slowdown, and
>> must be explicitly specialized for common numeric types to avoid it. (Has
>> this been fixed yet? Are there plans to?)
>>
>
> The underlying libraries provide optimized versions of matrix functions
> and Fourier transforms only for particular numeric types anyway. It'd be
> Swifty to have Matrix, but doing matrix multiplication with
> that simply isn't going to be performant.
>
>
>>
>> Nevin
>>
>>
>>
>> On Wed, Aug 3, 2016 at 8:41 AM, Björn Forster 
>> wrote:
>>
>>> Hello Swift community,
>>> to make use of Swift more appealing and useful for science, engineering
>>> and finance and everything else involving actually calculating things, I
>>> think it would be a big step forward if Swift would ship with its own
>>> math/numerics library.
>>>
>>> Wouldn't it be great if Swift would offer functionality similar to Numpy
>>> in its native math lib? It think it would be great to have a "standard"
>>> annotation for vector arithmetic that the Swift community has agreed on and
>>> that scientific packages can build on.
>>>
>>> Which functionality should be covered by a Swift's math lib and where
>>> should be drawn the line?
>>>
>>> Any thoughts?
>>>
>>> (If it is not the right time now to talk this topic, as it is not
>>> mentioned in the goals for Swift 4 by Chris, I apologize for bringing this
>>> up now. But I think then this should be discussed later at some point not
>>> in the infinite future)
>>>
>>> Björn
>>>
>>> ___
>>> 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] Swift 3.1 discussions, go?

[Muse M via swift-evolution]

I'm concern if simd could improve factorials code and faster timing.

import simd
func factorial(n: Int) -> Int {
return n < 1 ? 1 : n * factorial(n: n - 1)
}
print(factorial(n: 40))

On Wed, Aug 3, 2016 at 12:00 AM, Charlie Monroe 
wrote:

> That's a good point. :)
>
> On Aug 2, 2016, at 5:55 PM, Xiaodi Wu  wrote:
>
> I'm going to guess, since Musa mentioned science and engineering, that a
> good chunk of that work is floating point :)
>
>
> On Tue, Aug 2, 2016 at 10:41 AM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Are you using the variants of operators without overflow check? I.e.
>>
>> let num = a &+ b // [1]
>>
>> [1]
>> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
>>
>>
>>
>> On Aug 2, 2016, at 3:01 AM, Muse M  wrote:
>>
>> Have always wonder why Maths in Swift is slower than C and Go, it should
>> be address with priority if Swift is to be adopt for engineering, financial
>> and science industry.
>>
>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> See
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>>
>>> From what I understand, the discussion should stay focused on the main
>>> topics for Swift 4 that Chris highlighted in
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>>
>>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>>> the schedule...
>>>
>>>
>>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> It was stated that 27th of July was the last date for proposal
>>> acceptance, 29th of July was the last day for implementation, and 1th of
>>> August should be the starting day of Swift 3.1-related discussions.
>>> Am I right? Should we begin?
>>> ___
>>> 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] Swift 3.1 discussions, go?

[Muse M via swift-evolution]

Have always wonder why Maths in Swift is slower than C and Go, it should be
address with priority if Swift is to be adopt for engineering, financial
and science industry.

On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> See
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>
> From what I understand, the discussion should stay focused on the main
> topics for Swift 4 that Chris highlighted in
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>
> I had several ideas in mind, but am postponing them for Swift 5, seeing
> the schedule...
>
>
> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It was stated that 27th of July was the last date for proposal acceptance,
> 29th of July was the last day for implementation, and 1th of August should
> be the starting day of Swift 3.1-related discussions.
> Am I right? Should we begin?
> ___
> 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] [Swift4] Mailing list vs. Forum

[Muse M via swift-evolution]

We will need a platform that live near the code (repo). Contextual
switching is expensive for every developers especially lengthy discussions
could have save us man-hours.

On Sat, Jul 30, 2016 at 3:42 PM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> I have not enough experience with all the possible alternatives to give a
> vote for a specific system, but the mail-approach can be very tedious, and
> there are several things that a just not possible or very clumsy:
> - You can't edit a message that has been send
> - Tagging capabilities are very limited (no public tags…)
> - Searching & linking… (quite sure this has been mentioned extensively ;-)
> - Mail.app splits topics in strange ways, so it is very hard to follow
> discussions
>
> Sending a message is the only way of interaction, but imho it would be
> beneficial to have a lightweight alternative to just signal agreement (or
> something else) to posts.
> Receiving little or no feedback can be frustrating, and I expect there are
> many messages that didn't receive the attention they deserved, just because
> it is somewhat stupid to write an response that just says "absolutely
> right, I have nothing to add here" (feel free to prove me wrong ;-)
>
> Mailing lists have some benefits as well, but afaics, Discourse can
> basically run a list on top of all the discussions, so we wouldn't loose
> anything.
>
> Tino
> ___
> 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] [Swift4] Mailing list vs. Forum

[Muse M via swift-evolution]

I'm open to ZenHub that can be integrate as part of GitHub for discussion,
pull changes and it makes it easier to reference to the patches within
ZenHub than from Discourse or other forums. Swiftly right?

https://www.zenhub.com

On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution <
swift-evolution@swift.org> wrote:

> +1. Hirundo makes this format bearable, but it is still far from ideal. I
> see many advantages for using Discourse:
>
> - It has actual syntax highlighting.
> - It’s easier to moderate.
> - It supports real-time updates.
> - It’s easier to follow the flow of a conversation.
> - It has better search.
>
> I don’t doubt more people will take part in the Swift evolution process if
> we switch to Discourse.
>
> > Branching...
> >
> > On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via swift-evolution<
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > > On Jul 29, 2016, at 5:14 PM, Brandon Knope bkn...@me.com)>wrote:
> > > >
> > > >Chris, has the core team discussed opening up a forum for discussing
> proposal implementations.
> > > >
> > > >Some of us aren't as skilled as the core team or other contributors
> but would like to learn. A forum is a much easier place for us to post for
> code help and to help others with their questions. I think this could help
> get more involved as it would be a more comfortable format for them. Think
> of how there are Apple Developer forums and not mailing lists for iOS betas
> etc.
> > > >
> > > >I am not saying moving swift-evo to forums *yet* but I believe a lot
> of the newer programmers are more comfortable with a forum format,
> especially when it comes to help and discussing code.
> > > >
> > > >Forums for contributors would:
> > > >- be more familiar for a lot of the newer and not as experienced
> developers
> > > >- be easier to search
> > > >- be easier to moderate (not really a problem yet)
> > >
> > > Hi Brandon,
> > >
> > > Moving from email to a forum system has come up before, but they have
> some disadvantages.One of major wins of email is that it is pervasive and
> can be adapted into other forms.For example, if you haven’t seen it yet,
> check out:
> > > https://stylemac.com/hirundo/
> > >
> > > -Chris
> > >
> > We've discussed forums on swift-evolution before. Maybe it's time for
> another go, with Swift 3 winding down.
> >
> > For context, prior discussions are on this thread:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
> >
> > (-1 for mailman: it's hard for me to even properly find to all the
> prior discussion about mailing lists, because of how mailman's archive
> works...)
> >
> >
> > News in the last few days is that Gmane is at least temporarily
> disappearing:
> https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
> >
> >
> > I'd just like to vote once again forDiscourse(
> http://www.discourse.org/faq/#what):-Excellent web interface(
> https://meta.discourse.org/), from the people who brought you Stack
> Overflow(built-in search, etc.)
> > - Read via email if that's your thing: it has "mailing list mode" which
> includes 1-email-per-post, if that's your cup of tea
> > -Reply via email(
> https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)if
> that's your thing
> > - It'sopen source(https://github.com/discourse/discourse)itself
> > - I believe it has ways of getting content as JSON and/or RSS, so I'd
> hardly say "can be adapted into other forms" is an exclusive feature of
> email.
> >
> > And, Discourse providesfree hosting for community-friendly open-source
> projects(
> http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/).
> Istrongly suspect(
> https://twitter.com/jtbandes/status/705886542309363712)Swift would
> qualify for this.
> >
> >
> > There have been several people on this list arguing in favor of mailing
> lists — I encourage folks to go read the old thread for themselves.
> >
> > It's worth noting there are also plenty of voices that don't get heard
> on this list, because people just don't like using mailing lists. One
> example:
> https://twitter.com/pilky/status/755105431555608580___
> > 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] Seriously! Freeze Swift For Two Years After Release 3.0 !

[Muse M via swift-evolution]

I would disagree to freeze API for 2 years when a large parts of proposal
by brilliants programmers and scientists (that where performance is) have
yet to implement features in 3.1, 3.5 to 4.0​ would be ideally to move
fast, break fast before it reach mature stage.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-corelibs-dev] [swift-users] WWDC Meetup

[Muse M via swift-evolution]

I don't seem to see any outdoor activities for WWDC, make that a special
one for this year.

On Wed, Jun 8, 2016 at 3:59 PM, Chris Bailey via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi David:
>
> I didn't respond via the form, but will definitely be there if I can
> amongst other meetings/plans - I know a few other people that are in the
> same position. Keep us updated and thanks for organising!
>
> Chris
>
>
>
>
> From:David Hart via swift-corelibs-dev <
> swift-corelibs-...@swift.org>
> To:Jacob Bandes-Storch 
> Cc:Libs Swift Core , swift-users <
> swift-us...@swift.org>, Javier Soto , Shane S <
> electro_alch...@hotmail.com>, swift-evolution 
> Date:08/06/2016 07:10
> Subject:Re: [swift-corelibs-dev] [swift-evolution] [swift-users]
> WWDC Meetup
> Sent by:swift-corelibs-dev-boun...@swift.org
> --
>
>
>
> Thanks for everybody that took the time to fill the form! There were many
> more responses than I expected, so dinner becomes difficult to organise.
> But thanks to a hand from another community member, we should have a venue
> confirmed soon.
>
> We are currently shooting for *Tuesday evening*.
>
> More details coming ASAP.
>
> On 07 Jun 2016, at 08:46, David Hart <*da...@hartbit.com*
> > wrote:
>
> Of course, I wouldn’t want to exclude anybody by default! In that case,
> I’m proposing dinner somewhere.
>
> I’ve setup a Google Forms to help organise it:
>
> *http://goo.gl/forms/Oq6dK9fPNSCAVfL72*
> 
>
> On 07 Jun 2016, at 08:43, Jacob Bandes-Storch via swift-corelibs-dev <
> *swift-corelibs-...@swift.org* > wrote:
>
> +1 to both points :)
> On Mon, Jun 6, 2016 at 11:11 PM Javier Soto via swift-corelibs-dev <
> *swift-corelibs-...@swift.org* > wrote:
> I would love to join as well!!
>
> I'd like to propose perhaps to plan something alternative to beers to keep
> it inclusive to members who may not be 21 or like to drink alcohol :)
> On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution <
> *swift-evolution@swift.org* > wrote:
> +1  I'd love to put some faces to some names  :)  sounds fun!
>
> Shane
>
> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users <
> *swift-us...@swift.org* > wrote:
>
> I'd be interested in catching up. Was curious if there was going to be a
> meet up, either formal or informal. Sounds good.
>
> -Rod
>
> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution <
> *swift-evolution@swift.org* > wrote:
>
> I imagine that during WWDC a non-negligible proportion of the Swift Open
> Source contributors will be in or around San-Francisco. I’d very much like
> to profit from that opportunity to meet-up, get to know each other, talk
> Swift over some beers! Is anybody interested? If yes, any ideas for
> location? I can setup a Doodle once I see enough interest.
>
> Looking forward to meet you!
> ___
> swift-evolution mailing list
> *swift-evolution@swift.org* 
> *https://lists.swift.org/mailman/listinfo/swift-evolution*
> 
> ___
>
> swift-users mailing list
> *swift-us...@swift.org* 
> *https://lists.swift.org/mailman/listinfo/swift-users*
> 
> ___
> swift-evolution mailing list
> *swift-evolution@swift.org* 
> *https://lists.swift.org/mailman/listinfo/swift-evolution*
> 
> --
> Javier Soto
> ___
> swift-corelibs-dev mailing list
> *swift-corelibs-...@swift.org* 
> *https://lists.swift.org/mailman/listinfo/swift-corelibs-dev*
> 
> ___
> swift-corelibs-dev mailing list
> *swift-corelibs-...@swift.org* 
> *https://lists.swift.org/mailman/listinfo/swift-corelibs-dev*
> 
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Discussion: Why is "nil" not "none"

[Muse M via swift-evolution]

None would be similar to Null or nothing about the types in that sense
which None is not a type.
Nil would be interpret as Int, Float, String, etc



On Wed, Jun 8, 2016 at 9:17 AM, Dany St-Amant via swift-evolution <
swift-evolution@swift.org> wrote:

> No clue as to the origins, but if you insist on using none. you can do:
>
> let a : Int? = .none
> let b : Int? = .some(5)
>
> Using the simpler
>
> let a : Int? = nil
> let b : Int? = 5
>
> is just sugar.
> Maybe it was foresight to prevent people from saying, if I can do:
>
> let a : Int? = none
>
> Why can't I do:
>
> let b : Int? = some(5)
>
> And then go a step further by asking for all enum to be access without the
> leading dot; scary thought.
>
> So it may be better to stick with '.none' and sugared 'nil'.
>
> Dany
>
> Le 7 juin 2016 à 20:16, Brandon Knope via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> That's exactly the point I was going for.
>
> none makes more sense in this context than nil in my opinion
>
> Brandon
>
> On Jun 7, 2016, at 8:10 PM, Saagar Jha  wrote:
>
> Well, some is the opposite of none in that if I don’t have some, I have
> none. nil is just a carry-over from Objective-C.
>
> On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I guess for me it comes down to this:
>>
>> *Why were some and none chosen for as the cases for Optional?*
>>
>> As an extension of that, why does nil then represent none instead of the
>> obvious none?
>>
>> There has to be a reason why it's not:
>>
>> enum Optional {
>> case some(T)
>> case nil
>> }
>>
>> None seems a lot more expressive and consistent with Optional.
>>
>> I am comfortable and use to nil, but with swift being a new language, I
>> thought it was worth opening up a discussion about possibly changing
>> direction a little here.
>>
>> Thanks,
>> Brandon
>>
>> On Jun 7, 2016, at 7:57 PM, Jordan Rose  wrote:
>>
>> There are NilLiteralConvertible types other than Optional, but they’re
>> dwindling now that pointer nullability is represented by Optional. That
>> said, I’m not convinced renaming “nil” is worth it at this point.
>> Similarity with other languages is still a good thing.
>>
>> It’s true that we might not have picked nil if it hadn’t been for
>> Objective-C, but that doesn’t make it an invalid choice. There are lots of
>> things in Swift we might have done differently if it weren’t for
>> Objective-C and Cocoa.
>>
>> Jordan
>>
>>
>> On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> Quick thought:
>>
>>
>> If optional has a .none case, wouldn't it be more consistent to rename
>> nil to none?
>>
>>
>> Also, would nil make it into Swift if not for other languages?
>>
>>
>> It also might make it somewhat clearer:
>>
>>
>> var someInt: Int? = none //looks less like a pointer and more like a
>> value of nothing
>>
>>
>> 1. It is more consistent with the optional enum
>>
>> 2. The intent is arguably clearer
>>
>> 3. nil makes it seem like it's a pointer
>>
>> 4. Would nil be included if not for prior languages? Would "none" have
>> been chosen as the keyword if nil wasn't prior art?
>>
>>
>> One disadvantage is how close it is to .none, but with how common
>> nil/none is used, some syntactic sugar might make it look nicer than always
>> having the stray .
>>
>>
>> On vacation from Orlando, poolside, with a quick thought,
>>
>> Brandon
>>
>> ___
>>
>> 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
>>
> --
> -Saagar Jha
>
> ___
> 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] [Idea] A 128-bit unsigned integer value type

[Muse M via swift-evolution]

Most programming languages does have 128-bit of type except Swift.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Muse M via swift-evolution]

** What is your evaluation of the proposal?*
A novelty idea

** Is the problem being addressed significant enough to warrant a change to
Swift?*
Some programmers love compact code and make Swift no difference to other
languages, change is indeed easier and almost no barrier for all level of
readers.

** Does this proposal fit well with the feel and direction of Swift?*
It makes presentation slide and teaching readability and avoid information
overload when dealing large scale projects.

** If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?*
NIL


** How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?*
A glance at the code,


On Wed, May 11, 2016 at 7:19 AM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think actual keyword “where” provides enough of a delimiter that it
> won’t be hard to put something before it, and it seems unlikely to me that
> we would want to add anything *after* it without some *other* delimiter.
> So I’m not too concerned.
>
>
> Yeah, that’s my feeling as well.
>
> - Doug
>
>
> Jordan
>
> On May 10, 2016, at 14:29, Hooman Mehr via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Although handy for now, I am a bit concerned about moving `where` clause
> to the end of declaration. This reserves and occupies this wide open space
> at the end of declarations. I think we might find a better use for this
> space later as the language evolves. Any thoughts?
>
> On May 10, 2016, at 11:51 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello Swift community,
>
> The review of "SE-0081: Move where clause to end of declaration" begins
> now and runs through May 16. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Memorization for running function only once

[Muse M via swift-evolution]

Hi,

I propose* "*memorization" or "memo" keyword for a function that allows to
run only once through out the lifecycle in Swift 3. Repeatedly execute the
function will only return the same result without having to rerun the
function everytime.

memo func hello(fname: String, lname: String) {
   return fname.lname
}

This is useful for certain case for web application and value that don't
need change once executed.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution