Re: [swift-evolution] [Proposal] Random Unification

For a range of 0..<(2<

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md > > > What is your evaluation of the proposal? Generally +1 I would like the

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 1, 2017, at 11:05 AM, Erica Sadun via swift-evolution > wrote: > > I'd like to put forth that Gameplay Kit offers a perfectly cromulent model of > random number generation and API. Why not take that as a starting point, > Swiftify it so it becomes a cross

Re: [swift-evolution] Python Interop with Swift 4+

> I think you’re missing the idea here: the idea isn’t to provide exactly > syntax mapping of Ruby (or Python) into Swift, it is to expose the underlying > semantic concepts in terms of Swift’s syntax. In the case of Python, there > is a lot of direct overlap, but there is also some places

Re: [swift-evolution] Python Interop with Swift 4+

In ruby, parens are optional. So, v = foo.value and v = foo.value() are identical. There dot syntax is only used for method invocation, so there is no external access to instance variables without some twiddling; similarly getting access to a Proc/lambda/Method requires twiddling in Ruby

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 1:16 AM, David Hart via swift-evolution > wrote: > > Moreover, Ruby allows classes to have instance variables with the same name > as methods: > > class Foo > def initialize() > @bar = 5 > end > > def bar() > puts “Hello" >

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 17, 2017, at 4:09 PM, Xiaodi Wu via swift-evolution > wrote: > > > Certainly it's hard to defend Date.random (and yes, it might be useful for a > fuzzer, but that's a very niche use case--and in that case the fuzzer should > probably also generate

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 16, 2017, at 8:12 PM, Alejandro Alonso via swift-evolution > wrote: > > While this could work, I don’t believe this aligns with Swift. > SecRandomCopyBytes and arc4random_buf do it this way because of the languages > they were built in, and for

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 15, 2017, at 7:16 PM, Greg Parker via swift-evolution > wrote: > >> >> On Nov 15, 2017, at 5:53 PM, John McCall > > wrote: >> >>> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution >>>

Re: [swift-evolution] Adding Result to the Standard Library

For some generic function func doSomething() -> Result You could write (potentially pseudocode); func doSomething() throws -> String { return try doSomething().value() } with Result defined as: enum Result { case success(T) case error(Error) func value() throws -> T { switch self

Re: [swift-evolution] async void

>From what I understand, the C# and Swift designs are different: - C# async functions immediately return a task which can be enqueued to complete the work (including selecting which queue for UI cases, etc). Tasks have callback behavior attached to them. - Swift async functions immediately

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 4:23 PM, John McCall via swift-evolution > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md > > >

Re: [swift-evolution] continuations - "extensions on steroids" idea

My preference would be around features to aggregate functionality, or to provide proper mixing. 1. One simpler feature would be a way to indicate your implementation of a protocol is via a property, and that calls should be forwarded. 2. More complex mixin behavior would include the included

Re: [swift-evolution] [Proposal] Random Unification

I still would propose the random generator be designed as a random binary stream, with the user functionality being exposed on particular types (Int, Float, Array, etc) and not on that generator interface. For this I just picked a "read" method off of InputStream. One nice thing about a

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

I'm not attached to the name filteredMap, but having a specific signature for the optional version makes sense. I think the problem is that while Optional can be contemplated as a sequence of zero or one items, implicit conversion to Optional means anything can then be interpreted as a

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution > wrote: > > > I agree with Felix’s concern, which is why I brought up the question, but > ultimately the issue is unavoidable. It’s not down to global instance or not. > If your source of random numbers

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

> On Sep 12, 2017, at 11:00 AM, Xiaodi Wu via swift-evolution > wrote: > > Suppose instead this were about a protocol named Fooable and a requirement > called foo() that has a default implementation. Everything you just talked > about would apply equally. Am I to

Re: [swift-evolution] typed throws

> Typed throws is something we need to settle one way or the other, and I agree > it would be nice to do that in the Swift 5 cycle. > > For the purposes of this sub-discussion, I think there are three kinds of > code to think about: > 1) large scale API like Cocoa which evolve (adding

Re: [swift-evolution] floating point numbers implicit conversion

> On Jun 16, 2017, at 4:34 PM, Greg Parker <gpar...@apple.com > <mailto:gpar...@apple.com>> wrote: > > >> On Jun 16, 2017, at 10:35 AM, David Waite via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote

Re: [swift-evolution] floating point numbers implicit conversion

Has it been proposed to eventually make CGFloat into a typealias for Double to reduce the amount of explicit conversion necessary? (I realize as a proposal this would be better suited for corelibs-libfoundation) - For Apple platforms, eventually CGFloat will *always* be a Double value, as

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

> On Jun 13, 2017, at 3:21 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Jun 12 2017, David Waite > wrote: > >> So is the idea of the Index struct is that the encodedOffset is an >>

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

> On Jun 9, 2017, at 9:24 PM, Dave Abrahams via swift-evolution > wrote: > on Fri Jun 09 2017, Kevin Ballard > wrote: >> On Tue, Jun 6, 2017, at 10:57 AM, Dave Abrahams via swift-evolution wrote: >> >>

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 9:12 AM, Gor Gyolchanyan via swift-evolution > > wrote: > >> >> So I wonder if any of you have had any thoughts about what Swift's >> parentheses-related future (or evolutionary baggage) will be? >> > > I

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

tation it will bridge to the target type in > all scenarios, no matter if it is created in objc or in swift. > >> On May 19, 2017, at 9:00 PM, David Waite via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> When I c

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

I believe behavior depends on whether the NSNumber is the objc type or swift subtype, and whether you call the NSNumber.intValue or use Int.init?(exactly: NSNumber). My point is that there is no intuitive or safe generalized behavior for treating arbitrary NSNumbers as an Int? . If an

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

When I call such a mapped Swift API that expects an Int? parameter from Objc with a NSNumber initialized with 3.5, what should happen? [NSNumber uint64value: UINT64_MAX] ? What about the float 1e100? What about boolean 'true’? NaN? -DW > On May 19, 2017, at 8:54 PM, Jonathan Hull via

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

> On May 15, 2017, at 8:24 AM, T.J. Usiyan via swift-evolution > wrote: > > The argument is not about whether or not it should come through as an object. > The argument is about the fact that *sometimes* it would come through as an > object and other times it would

Re: [swift-evolution] [Pitch] Never as a bottom type

> On May 14, 2017, at 11:44 PM, André Videla via swift-evolution > wrote: > >> Joe also referred to the following model in a thread about Typed Throws. >> >> () -> () == () throws Never -> () >> () throws -> () == () throws Error -> () > That makes sense! As a

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

> On May 3, 2017, at 2:09 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution >> > wrote: >> >> I definitely agree that it's a feature that

Re: [swift-evolution] [pitch] Comparison Reform

ty and total ordering. This would mean that Equatable/Comparable generic algorithms are forced to always use total ordering algorithms without the chance of having a conflict with floating point operators - because the naming no longer conflicts. -DW > > > On Apr 24, 2017, at 9:44 PM, Davi

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 24, 2017, at 11:52 PM, Jonathan Hull via swift-evolution > wrote: > > The only other alternative I can think of is to include a notion of unordered > to our comparisons… > > What if we made <=> return an optional comparison result, with nil meaning >

Re: [swift-evolution] [pitch] Comparison Reform

I still think this is a naming conflict more than anything else. The first expectation is that equatable and comparable provides strict equality and strict total ordering, and that those are exposed via operators. The other expectation is that floating point abides by the IEEE rules which have

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution > wrote: > > I don’t think that this proposal is acceptable as written. I think it is > really bad that abstracting a concrete algorithm would change its behavior so > substantially. I don’t care

Re: [swift-evolution] [pitch] Comparison Reform

To me, there are two proposals here, partly interrelated but worth considering separately. 1. Use of @_implements to allow floating point to have an IEEE implementation of operators, while still having Comparable implement strict total order across every unique value (NaN.) This includes

Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

> On Apr 18, 2017, at 1:00 AM, David Hart via swift-evolution > wrote: > > All controversial proposals start their implementation in that version. Just one more note here, in regards to SE-0025 Its important to realize that the swift evolution process isn’t a pure

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

Afraid I have to agree - this proposal obviously had a lot of thought put into it, but my opinion is that this level of complexity disguises the purpose of access control. The goal of access control (again IMHO) should be to support reduced coupling and encapsulation. The goal is to both

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 9, 2017, at 8:44 PM, Brent Royal-Gordon via swift-evolution > wrote: > > To back up that last point, I ran through the thread and tried to quickly > figure out what everyone was thinking. These people seem to be opposed to the > proposal: > > 2.

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

On Apr 9, 2017, at 7:04 PM, Jose Cheyo Jimenez via swift-evolution wrote: > > On Apr 8, 2017, at 5:19 AM, Neil via swift-evolution > > wrote: > >> I agreed with Charlie, but I think there’s another option.

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 6, 2017, at 1:35 PM, Joe Groff via swift-evolution > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > >

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

> On Apr 5, 2017, at 12:39 PM, John McCall via swift-evolution > wrote: > > Hello, Swift community! > > The review of "SE-163: String Revision: Collection Conformance, C Interop, > Transcoding" begins now and runs through next Tuesday, April 11th. The > proposal

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

Even with a closure, at the point of use it would likely be clear that the value is being used as a boolean condition - vs “filter” which returns an array. -DW > On Apr 5, 2017, at 4:06 PM, Jarod Long via swift-evolution > wrote: > > I don't think an argument label

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 5, 2017, at 3:27 PM, Tony Arnold via swift-evolution > wrote: > > >> On 6 Apr 2017, at 02:54, Nevin Brackett-Rozinsky via swift-evolution >> wrote: >> >> The developer adds a free function to the file. Or an extension of

Re: [swift-evolution] Make class and struct members private by default / Type-Based access

> On Apr 4, 2017, at 7:07 AM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi Xiaodi, > > that currently all members of a class or struct are exposed by default by > having > a default scope of ‘internal’ and are therefore accessible in the entire >

Re: [swift-evolution] Type-based ‘private’ access within a file

Soft -1 for four reasons: 1. I would expect private to be used to hide implementation details and type invariants from all code, to encapsulate and protect the unsafe bits. Think the possibility to put the instance into an illegal state, or to modify its state outside of its defined threading

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

> > https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md > > > * What is your evaluation of the proposal? Mixed opinion. I feel the rules would be simpler if we

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 20, 2017, at 5:54 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0159 "Fix Private Access Levels" begins now and runs through > March 27, 2017. The proposal is available here: > >

Re: [swift-evolution] [Draft] Hasher & HashVisitable

It would be possible for a Hasher to return varying types, but then people might want the interface to support cryptographic hashing as well as variable length hashes (for things like HAMT) -DW > On Mar 14, 2017, at 4:56 PM, Greg Parker via swift-evolution > wrote:

Re: [swift-evolution] Swift null safety questions

For bridged legacy code without nullability specifiers, IUOs basically save a few characters at the cost of potential crashing bugs. I’m believe there would have been a much stronger push to eliminate IUOs from the language before Swift 3 if this were the only use. For legacy properties, there

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

This works because your properties are read-only, thus allowed to be covariant. If you add a setter, the compiler will complain. -DW > On Mar 10, 2017, at 5:33 AM, Anton Zhilin via swift-evolution > wrote: > > Looks like a compiler bug, since it works with classes:

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

The getter is covariant while the setter is contravariant. The result is read/write properties are invariant. Objective-C basically considers declared types to be advisory (to generate compiler warnings). In reality, both delegate properties are of type ‘id’, with type issues surfacing at

Re: [swift-evolution] [Draft] Fix ExpressibleByStringInterpolation

> On Mar 10, 2017, at 9:49 AM, Joe Groff via swift-evolution > wrote: > > Having ExpressibleByStringInterpolation refine ExpressibleByStringLiteral > makes sense. I think there's a more powerful alternative design you should > also consider. If the protocol looked

Re: [swift-evolution] [Discussion] Simplifying case syntax

I don’t fully understand - are you saying to comment on the gist as if it were a discussion forum? -DW > On Mar 7, 2017, at 1:25 PM, Erica Sadun via swift-evolution > wrote: > > I've put together everything I have about cases and unwrapping here: > >

[swift-evolution] A Modest (multi-module) Proposal

Apologies on creating yet another modulary thread in parallel, but I don’t believe I have seen the approach I’ve been mulling over considered. I have been contemplating submodules not from an access scoping perspective, but from a packaging one. In other words rather than defining the ability

Re: [swift-evolution] Random

> On Mar 4, 2017, at 3:21 AM, Haravikk via swift-evolution > wrote: > >> >> On 4 Mar 2017, at 06:58, Charlie Monroe via swift-evolution >> > wrote: >> >> While I am not against the idea, I believe that

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 27, 2017, at 2:08 PM, Matthew Johnson <matt...@anandabits.com> wrote: > >> >> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Add more l

Re: [swift-evolution] [Pitch] Typed throws

IMHO, there are two kinds of responses to errors - a specific response, and a general one. Only the calling code knows how it will deal with errors, so a “typed throws” is the function guessing possible calling code behavior. The problem is, that gives four possible combinations - two where the

Re: [swift-evolution] Strings in Swift 4

> On Feb 25, 2017, at 2:54 PM, Michael Ilseman <milse...@apple.com> wrote: > > >> On Feb 25, 2017, at 3:26 PM, David Waite via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Ted, >>

Re: [swift-evolution] Strings in Swift 4

Ted, It might have helped if instead of being called String and Character, they were named Text and ExtendedGraphemeCluster. They don’t really have the same behavior or functionality as string/characters in many other languages, especially older languages. This is because in many languages,

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 23, 2017, at 2:56 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > The prevailing view from recent discussions is that there should be just one > access level more fine-grained than ‘internal’, and it should be spelled > ‘private’. Let us

Re: [swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

> On Feb 22, 2017, at 5:32 PM, Ben Cohen via swift-evolution > wrote: > >> On Feb 22, 2017, at 10:42 AM, Nate Cook via swift-evolution >> > wrote: >> >> Oops, left out that there's this horrifying way of

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 21, 2017, at 2:27 AM, Joanna Carter > wrote: > > But in the Swift world, we now have the ability to extend almost any type, > except Any and AnyObject, which appear to be protected by some deep and dark > mechanism within the compiler. So, just as

Re: [swift-evolution] 'Public' class visibility specifiers

> On Feb 21, 2017, at 3:47 AM, Joanna Carter via swift-evolution > wrote: > > >> Le 21 févr. 2017 à 10:28, Slava Pestov a écrit : >> >> There is one important difference, but it is rather obscure. ‘final’ allows >> a class to conform to

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 20, 2017, at 10:04 AM, Joanna Carter via swift-evolution > wrote: > > Otherwise known in my language as : > > public - anywhere > internal - anywhere inside the module > private - only inside current type > extensible - in current file and in

Re: [swift-evolution] [Draft] open and public protocols

nditionFail if a different type other than String, Int, or IntMax is passed in. -DW > > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 19. Februar 2017 um 07:59:45, David Waite via swift-evolution > (swift-evolution@swift.org <mailto:swift-evoluti

Re: [swift-evolution] [Draft] open and public protocols

> On Feb 19, 2017, at 4:18 PM, Xiaodi Wu via swift-evolution > wrote: > > On Sun, Feb 19, 2017 at 5:10 PM, Adrian Zubarev > > > wrote: > Because someInstance["key", .string("key1"),

Re: [swift-evolution] final + lazy + fileprivate modifiers

Swift 2’s access modifiers had a very simple ‘elevator pitch’ - “If you are writing code, by default everything within the module (app or library) your are working in can see it, but other modules cannot. If you want other modules to see features of your module, you make them public. If

Re: [swift-evolution] [Draft] open and public protocols

wift:194 _NSStringCore > /swift/stdlib/public/SDK/Foundation/NSError.swift:353 > _ObjectiveCBridgeableError > /swift/stdlib/public/SDK/Foundation/NSError.swift:379 __BridgedNSError > /swift/stdlib/public/SDK/Foundation/NSError.swift:446 _BridgedNSError > /swift/stdlib/publ

Re: [swift-evolution] [Draft] open and public protocols

I am unsure if this feature is a good idea. Does someone have a real-world use for this which isn’t just hiding strong implementation coupling behind a protocol? When I consume a protocol, it is under the assumption that the protocol is documented such that I would be able to work against

Re: [swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

> On Feb 18, 2017, at 12:40 AM, Xiaodi Wu wrote: > > On Sat, Feb 18, 2017 at 1:07 AM, David Waite > wrote: > > I believe this proposal is different in that it only requires specification > for clarity

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

> > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md > > > > What

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 5:26 PM, Ben Cohen via swift-evolution > > wrote: > > Hi swift-evolution, > > Following up on Ted’s post regarding the opening up of stage 2, I’m starting > a thread to discuss improvements to the Dictionary

Re: [swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

> On Feb 17, 2017, at 10:53 PM, Xiaodi Wu wrote: > > This draft proposes something that's been discussed on this list several > times over the past few years, but now with a different spelling. However, > previous objections never centered around the spelling. > > As

[swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

I wrote up the following draft proposal around attempting to clarify protocol implementation and protocol extensions, via annotating methods and properties meant to satisfy protocol requirements with additional keywords: "Types implementing protocols with optional features (either through

Re: [swift-evolution] Sequence/Collection Enhancements

> On Feb 16, 2017, at 5:39 PM, Ben Cohen via swift-evolution > > wrote: > > Hi swift-evolution, > > Following up on Ted’s post regarding the opening up of stage 2, I’m starting > a thread to discuss additive algorithms for Sequence

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution > > wrote: > > As I have said elsewhere, I think the mental anguish mostly derives from the > fact that scoped private is not the right “default” in a language that

Re: [swift-evolution] final + lazy + fileprivate modifiers

The primary point of access modifiers is communication, with the secondary point of something like ‘internal’ or ‘final’ to be compiler optimization. Other languages do just fine with just having naming conventions for implementation details, rather than having the compiler enforce that

Re: [swift-evolution] [Pitch] consistent public access modifiers

Types have a ton of different implicit/explicit “API”, and access control modifiers often implicitly define that API: - API for everyone to use when dealing with your concrete type (“public”) - API for module code when you have related, coupled types that need a higher degree of knowledge

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

If someone came with a nice syntax I’d be for this. I can’t imagine what that would be. I doubt there is an alternate prefix or postfix operator that would pass muster, due to ‘!’ already meaning the appropriate thing in so many languages, and swift only supporting symbolic operators. I can’t

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 15, 2017, at 5:00 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution >> wrote: >> >> Keeping with the spirit of Swift and staying consistent with its design, I

Re: [swift-evolution] Overriding protocol default implementation

> On Feb 10, 2017, at 12:41 PM, Robert Ryan via swift-evolution > wrote: > I’m hard pressed to think of a situation where you’d want the current Swift 3 > behavior of the first example (where you can override a protocol default > implementation but you only want

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

> On Feb 7, 2017, at 7:23 AM, Derrick Ho via swift-evolution > wrote: > > I have found it strange that operator characters are the only ones that may > be used as operators. Sometimes Characters that look like operators are not. > > Why does there need to be a

Re: [swift-evolution] Strings in Swift 4

> On Feb 6, 2017, at 10:26 AM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi Dave, > Oops! yes, you’re right! > I did read again more thoroughly about Unicode > and how Unicode is handled within Swift... > -should have done that before I write something-

Re: [swift-evolution] Strings in Swift 4

> On Feb 6, 2017, at 10:26 AM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi Dave, > Oops! yes, you’re right! > I did read again more thoroughly about Unicode > and how Unicode is handled within Swift... > -should have done that before I write something-

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

Actually, several projects (Mozilla and WebKit spring to mind) both have historically had issue trackers as an essential organization tool, for just about everything from planning a new feature to organizing T-Shirt sizes for user meet ups. Issue trackers work really well for proposals as

Re: [swift-evolution] warnings for out of scope?

> On Jan 26, 2017, at 10:21 AM, Joe Groff via swift-evolution > wrote: > > >> On Jan 25, 2017, at 10:40 AM, Xiaodi Wu via swift-evolution >> wrote: >> >> This is contrary to several deliberate design decisions, if I understand >>

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

I meant more that we are dependent on Apple to actually change the existing official infrastructure to some new system. If all we want is an unofficial forum, any one of us could set that up now and invite people over for talk and snacks. I assume swift-evolution is more of a meritocracy than

Re: [swift-evolution] Default Generic Arguments

You do have empty angle brackets today, which indicate an inferred generic argument rather than a defaulted generic argument. See: 1> let a = 1 a: Int = 1 2> let b:Optional = a b: Int? = 1 If Swift had defined Optional as Optional, statement 2 would be ambiguous. I have a hard time coming

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

As long as we are pretending this bike shed is getting painted again… I would actually prefer something closer to an issue tracker than discourse. We get a lot of repeat and diverging topics, and it would be nice to mark discussions as related, duplicates, etc -DW > On Jan 23, 2017, at 9:22

Re: [swift-evolution] HTML rendering output (was: Strings in Swift 4)

With the current model, I’d make a first pass of this sort of functionality by doing: 1. Define a HtmlEncoded wrapping struct that indicated a value was meant to be safe to output directly, rather than be encoded. This would make encoding safe by default (opt out) 2. HTML content built via

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

> On Jan 17, 2017, at 1:38 PM, Dave Abrahams via swift-evolution > wrote: > > It also means, from a purely pragmatic view, that control flow for > things that are really not reliably recoverable conditions (like index > out-of-range) is not cleanly separated from

[swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

My interpretation is that he was advocating a future where a precondition’s failure killed less than the entire process. Instead, shut down some smaller portion like a thread, actor, or container like .Net's app domains (which for those more familiar with Javascript could be loosely compared

Re: [swift-evolution] Fixing raw enum types

Or perhaps paint the bikeshed enum Something<(Int32, Int32)> { … } -DW > On Jan 16, 2017, at 11:51 AM, Anton Zhilin via swift-evolution > wrote: > > This idea by Karl made me branch off a new thread. > > 2017-01-16 21:28 GMT+03:00 Karl Wagner

Re: [swift-evolution] Consolidate Code for Each Case in Enum

> Enum cases _feel_ like separately defined, but tightly related structs > because each case can have distinct associated values. They have special > privileges that a family of structs doesn't have, like `self = .otherCase`. > Enums are really awesome. I think this is the primary difference

Re: [swift-evolution] Move placement of 'throws' statement

Imho the concept of checked exceptions was ok, but the important information is the category of error - in how to respond and how to report to the user. Use of a type system encourages an ontology of errors by subsystem and not by appropriate programmatic response. You could have appropriate

Re: [swift-evolution] Move placement of 'throws' statement

Although I have only partially vetted it myself, this came up for a google search: http://wiki.c2.com/?JavaExceptionsAreParticularlyEvil -DW Sent with my Thumbs > On Dec 27, 2016, at 5:56 AM, Derrick Ho via swift-evolution > wrote: > > Daniel Leping, I am

Re: [swift-evolution] Generic types―covariance/contravariance

I wouldn’t keep it that narrow - monadic types like Optional also benefit from variance: func p(_ data:Any?) { if data != nil { data.map { print($0) } } } var a:String? = "foo" p(a) // -> “foo" -DW > On Dec 9, 2016, at 12:24 PM, Hooman Mehr via swift-evolution >

Re: [swift-evolution] What about renaming Optional.map to Optional.mapMe ?

This might be a bit of a side question, but do you use optional arrays in your code? If so, what is the distinction between no array and an empty array? I believe I haven’t had this confusion in practice because I assume “cars” is a collection, not an optional. -DW > On Dec 5, 2016, at 8:46

Re: [swift-evolution] Global init() functions

In the past, I’ve seen issues with these sorts of module initialization functions: - They promote a high degree of coupling between a module and its dependencies. Given an example of a test framework, you’ll see tests which support a single implementation of a test runner, with a globally

Re: [swift-evolution] Fwd: about protocols

A static method or property on a protocol already means something separate - that the types which implement that protocol that static method/property. I’d recommend moving your factory method to another type or a global function? -DW > On Nov 15, 2016, at 10:10 AM, Reynaldo Aguilar Casajuana

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 10:37 AM, Chris Lattner via swift-evolution > wrote: > > To me, this is the most promising direction, but I’d suggest the use of > “unwrap" as the keyword. If you compare these two: > > a) guard let foobar = foobar else { … } > b) guard

  1   2   3   >