Re: [swift-evolution] Closures from methods with default args

> On Jan 19, 2017, at 23:26, Xiaodi Wu wrote: > > Hmm, I don't recall the earlier discussion, It was a *long* time ago. I'll see if I can find it. If I'm misremembering, then... > but IMO, Charlie's proposal is pretty sensible. Seems backwards to adding > much broader things like default argu

Re: [swift-evolution] Closures from methods with default args

> On Jan 20, 2017, at 00:09, David Sweeris via swift-evolution > wrote: > > >> On Jan 19, 2017, at 23:26, Xiaodi Wu wrote: >> >> Hmm, I don't recall the earlier discussion, > It was a *long* time ago. I'll see if I can find it. If I'm mis

Re: [swift-evolution] Epic: Typesafe calculations

Same here. I can fake a bit of it now by creating the relevant types ("struct _1 {...}", etc), but it's *very* fragile. > On Dec 31, 2015, at 14:18, Matt Whiteside via swift-evolution > wrote: > > >>> On Dec 31, 2015, at 09:25, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> On D

Re: [swift-evolution] [proposal] Allow trailing closures in 'guard' conditions

+1 > On Mar 23, 2016, at 01:03, Chris Lattner via swift-evolution > wrote: > > Hi everyone, > > This is a proposal for a very narrow extension to the guard statement. I > consider it to be a bug fix, but since it is a language extension, I feel > that it should go through the evolution proc

Re: [swift-evolution] Deprecating Trailing Closures

Agreed. Sent from my iPhone On Mar 25, 2016, at 07:44, Brent Royal-Gordon via swift-evolution wrote: >>>let foo = myArray >>>.filter { $0 & 1 == 1 } >>>.map { $0 + 1 } >>>.reduce(0) { $0 + $1 } >> >> This doesn’t really seem much neater or more readable to me than:

Re: [swift-evolution] [swift-users] pattern matching in if improvement?

I'm not where I can check, but is "=~" taken? Sent from my iPhone > On Mar 26, 2016, at 22:19, Lukas Stabe via swift-users > wrote: > > > An alternative may be to introduce a custom operator that just calls `~=` > with the arguments reversed, but imho this should rather be fixed at the > la

Re: [swift-evolution] Allowing Characters for use as Custom Operators

• is the dot product operator. Sent from my iPhone > On Mar 28, 2016, at 10:21, Thorsten Seitz via swift-evolution > wrote: > >> Am 08.01.2016 um 09:38 schrieb Jacob Bandes-Storch via swift-evolution >> : >> >> I'd be hesitant to support something like this. • is a very natural choice >> fo

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

> On Apr 2, 2016, at 20:49, Charles Srstka via swift-evolution > wrote: > > While this style works, and definitely can substitute for a classical for > loop, it is not quite as nice, because it cannot limit i’s scope to the loop. > The variable will be visible outside of the loop body. I agr

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution > wrote: > > Hi Dave, > > Thanks for bringing up this topic. This has been kicked around a little, and > we’re still exploring different models on how to extend Swift. > > The server APIs work group is one operational model for

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 22:54, Douglas Gregor via swift-evolution > wrote: > >> On Nov 21, 2017, at 10:48 PM, David Hart wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution >> wrote: >> >>> >>> On Nov 21, 2017, at 10:37 PM, Chris Lattner wrote: >>>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 25, 2017, at 08:05, Xiaodi Wu via swift-evolution > wrote: > > >> On Sat, Nov 25, 2017 at 06:35 Mike Kluev wrote: >>> On 25 November 2017 at 03:12, Xiaodi Wu wrote: >> On Fri, Nov 24, 2017 at 9:08 PM, Mike Kluev via swift-evolution wrote: >>> > On 24 November 2017

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Sent from my iPhone > On Nov 30, 2017, at 00:24, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution >> wrote: >> >> I’d like to formally propose the inclusion of user-defined dynamic member >> lookup types. >> >> Here is

Re: [swift-evolution] [pitch] adding toggle to Bool

> On Jan 11, 2018, at 22:15, Chris Eidhof via swift-evolution > wrote: > > Hey SE! > > When we have a bunch of nested structs: > > struct Sample { > var bar: Bar > } > > struct Bar { > var show: Bool > } > > var foo = Sample(bar: Bar(show: false))

Re: [swift-evolution] [Pitch] Percentage Type

Sent from my iPhone > On Jan 16, 2018, at 23:45, Jonathan Hull via swift-evolution > wrote: > > Mainly semantics. > > We could technically use Int instead of having a Bool type (just using 1 and > 0). We don’t do that since Int and Bool have intrinsically different > meanings in code. >

Re: [swift-evolution] Strings in Swift 4

> On Jan 22, 2017, at 15:40, Chris Lattner via swift-evolution > wrote: > > Right, the only sensible semantics for a one sided range with an open end > point is that it goes to the end of the collection. I see a few different > potential colors to paint this bikeshed with, all of which would

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

> On Jan 23, 2017, at 09:59, Joshua Alvarado via swift-evolution > wrote: > > It will be painted! ;) > > So far we have: > +2 Disclosure > +1 Slack > +1 Issue tracker > > Let's really get everyone's opinions and see if we can get this rock rolling > towards a better solution. Of course it w

Re: [swift-evolution] Default Generic Arguments

> On Jan 24, 2017, at 11:41, Alexis via swift-evolution > wrote: > > It’s worth noting that the question of “how do these defaults interact with > other defaults” is an issue that has left this feature dead in the water in > the Rust language despite being accepted for inclusion two years ago

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 25, 2017, at 07:59, Anton Mironov via swift-evolution > wrote: > > Hi everyone, > > I want to suggest a tiny extension to an Arithmetic protocol. It would be > nice to have an additive identity and a multiplicative identity constants. > Basically zero and one. > > ``` > protocol Ar

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 25, 2017, at 10:03, Xiaodi Wu via swift-evolution > wrote: > > Stephen Canon wrote that Arithmetic should refine ExpressibleByIntegerLiteral > because of certain mathematical properties of rings. In that case, 0 and 1 > would just be spelled in that way. Otherwise, +1. >> On Wed, Jan

Re: [swift-evolution] Default Generic Arguments

> On Jan 24, 2017, at 15:33, Xiaodi Wu wrote: > > As I replied above, this doesn't work IMO because omitted generic arguments > are inferred, and that can't change without being hugely source-breaking. > > I think it's absolutely essential that adding a default to my library doesn't > change

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 13:02, Rick Mann via swift-evolution > wrote: > > Thanks for that, that's helpful. > > My concern, of course, is the obvious one: that we'll have to compromise on > future functionality in order to not break ABI compatibility, or we'll have a > painful transition when w

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 8:59 AM, Charlie Monroe via swift-evolution > wrote: > > >> On Jan 27, 2017, at 5:43 PM, Tino Heth <2...@gmx.de > >> wrote: >> - runtime libraries for Swift 4 - all system frameworks will need to contain two variants - one compatible

Re: [swift-evolution] Default Generic Arguments

> On Jan 27, 2017, at 1:43 PM, Anton Zhilin via swift-evolution > wrote: > > Current alternative to default generic arguments is typealias, like > basic_string and string in C++: > > struct BasicBigInt { ... } > typealias BigInt = BasicBigInt > It’s not that ugly. It keeps type inference rule

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 13, 2017, at 12:47, Max Moiseev via swift-evolution > wrote: > DoubleWidth > The DoubleWidth type allows to create wider fixed-width integer types from > the ones available in the standard library. > > Standard library currently provides fixed-width integer types of up to 64 > bits.

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 29, 2017, at 10:36, Xiaodi Wu wrote: > > Hmm, interesting. I might be tempted to use a 40-bit type for large arrays, > but the performance hit for any useful computation over a large array would > probably tilt heavily in favor of plain 64-bit integers. What's your use case > for suc

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 29, 2017, at 12:13, Xiaodi Wu wrote: > >> On Sun, Jan 29, 2017 at 2:03 PM, David Sweeris wrote: >> >>> On Jan 29, 2017, at 10:36, Xiaodi Wu wrote: >>> >>> Hmm, interesting. I might be tempted to use a 40-bit type for large arrays, >>> but the performance hit for any useful computat

[swift-evolution] Public struct init is unexpectedly internal

So I’ve got this code in a package called “SomeLib": public struct SomeType { public var text = "SomeText" } and then, in another package, write this: import SomeLib print(SomeType().text) and then run swift build, I get this error: error: 'SomeType' initializer is inaccessible due to 'internal

Re: [swift-evolution] Public struct init is unexpectedly internal

> On Jan 30, 2017, at 1:21 AM, Slava Pestov wrote: > >> >> On Jan 30, 2017, at 1:12 AM, David Sweeris via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> So I’ve got this code in a package called “SomeLib": >> public

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0150 Package Manager Support for branches

> On Jan 24, 2017, at 10:18 AM, Daniel Dunbar wrote: > > Hello Swift community, > > The review of SE-0150 “ Package Manager Support for branches" begins now and > runs through January 31, 2017. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/propos

Re: [swift-evolution] Initializers

> On Jan 30, 2017, at 12:36 PM, Robert Widmann via swift-evolution > wrote: > > This seems to contradict Swift’s goal of being safe by default > , no? IIUC, it wouldn’t contradict that goal if the compiler could guarantee that everything still gets initialized. I do

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

> On Jan 30, 2017, at 8:14 PM, Xiaodi Wu via swift-evolution > wrote: > > Just left a comment on the bug; it's clear we need some sort of new syntax, > and I'd like to throw out `foo(:)` as a candidate, by analogy with `[:]` > being an empty dictionary. Works for me. - Dave Sweeris ___

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 11:32, Jaden Geller via swift-evolution > wrote: > > I think that is perfectly reasonable, but then it seems weird to be able to > iterate over it (with no upper bound) independently of a collection). It > would surprise me if > ``` > for x in arr[arr.startIndex…] { prin

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 3:36 PM, David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > On Jan 31, 2017, at 11:32, Jaden Geller via swift-evolution > mailto:swift-evolution@swift.org>

Re: [swift-evolution] The lack of namespaces is leading people astray

> On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution > wrote: > > The lack of namespaces is making people create all kinds of "design patterns". > > struct API { > static let endpoint = "http://example.com/api " > } > > Here is an "improvement" to the abov

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 3:01 PM, David Hart via swift-evolution > wrote: > > > On 1 Feb 2017, at 22:54, Douglas Gregor > wrote: > >> >>> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> This is a nic

Re: [swift-evolution] Proposal seed: gathering data to fix the NSUInteger inconsistency

> On Feb 2, 2017, at 09:52, Freak Show via swift-evolution > wrote: > > Yeah, that's what I want - more "annotations" cluttering up my Objective C > headers to make Swift happy. > > No thanks. There's enough noise introduced already. It'd be cluttering up Apple's code, not yours (unless you

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

> On Feb 9, 2017, at 09:30, Matthew Johnson via swift-users > wrote: > > >>> On Feb 9, 2017, at 11:16 AM, Jens Alfke via swift-users >>> wrote: >>> >>> >>> On Feb 9, 2017, at 3:41 AM, Jan Neumüller via swift-users >>> wrote: >>> >>> I would prefer http://www.fudforum.org/ that has good

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 11:27 AM, Sean Heber via swift-evolution > wrote: > > Doesn’t this break down if you can pass a reference as a parameter to a pure > function? If that’s not allowed, I guess I must have missed it. Also this > seems to require the function has a return value. I suppose ge

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 13:10, Dennis Weissmann via swift-evolution > wrote: > > Secondly, are they inherited? So if ClassA has a pure function a(), can I > override it in subclass ClassB: ClassA to be impure? (I think no) I would agree. IIUC, the "pureness" of A's implementation of a() becomes

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 4: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 type. > > Here is a list of commonly requested changes/enhanceme

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 3:13 PM, David Hart via swift-evolution > wrote: > > Now that I've thought more about it, I have a question. Escaping/unescaping > is an important concept to have in the language: if the API provider makes > the promise that a closure is non-escaping, the API client does

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 5:17 PM, Ben Cohen wrote: > > The win with mapping only the values is that the underlying hash table can > retain the same physical layout, just with different values in the slots, so > it can be done faster. Only if the mapped dictionary’s values are the same type (or a

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 17:45, Ben Cohen wrote: > > >>> On Feb 16, 2017, at 5:38 PM, Slava Pestov wrote: >>> >>> >>>> On Feb 16, 2017, at 5:32 PM, David Sweeris via swift-evolution >>>> wrote: >>>> >>>> &g

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 18:00, Slava Pestov wrote: > > >>> On Feb 16, 2017, at 5:15 PM, David Sweeris via swift-evolution >>> wrote: >>> >>> >>> On Feb 16, 2017, at 3:13 PM, David Hart via swift-evolution >>> wrote: >>&g

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

> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution > wrote: > > While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary complications that > only serve to

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution > wrote: > > I haven’t yet read all the feedback in this topic but I’d like to throw some > bikeshedding of mine into the room. :) > > How about this? > > Version 1: func(pure) … > Version 2: func label(…) ~> ReturnType Version

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 08:49, Matthew Johnson wrote: > > >> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution >> wrote: >> >> >> On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution >> wrote: >> >>> I hav

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

Sent from my iPhone > On Feb 17, 2017, at 01:02, Rien wrote: > > >> On 17 Feb 2017, at 03:36, David Sweeris via swift-evolution >> wrote: >> >> >>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 9:51 AM, André “Zephyz” Videla via swift-evolution > wrote: > >> But given the scope capturing nature of closures I was actually wondering if >> this 'purity' should be applied to closures. > I think It should, pure closure cannot have outside references and therefore >

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

> On Feb 17, 2017, at 9:48 AM, Xiaodi Wu via swift-evolution > wrote: > > What you are really asking for is a way of flexibly designating a "unit of > code" within a module, for which the general solution is submodules. The > objection is that, instead of tackling that issue, these are sugges

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> On Feb 17, 2017, at 10:38 AM, Abe Schneider via swift-evolution > wrote: > > If I read Nicolas's post correctly, I think he's more arguing for the > ability to create syntax that allows Swift to behave in a similar way > to Numpy/Matlab. While Swift already does allow you to define your own >

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> On Feb 17, 2017, at 10:51 AM, Xiaodi Wu wrote: > > > On Fri, Feb 17, 2017 at 12:46 PM, David Sweeris > wrote: > >> On Feb 17, 2017, at 10:38 AM, Abe Schneider via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> If I read Nicolas's post correc

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

> On Feb 17, 2017, at 10:45 AM, Anton Zhilin via swift-evolution > wrote: > > Now this is on-topic, I guess. > Last time we stopped at John McCall’s syntax: > > extension MyError: Error { ... } > > func foo() throws(MyError) -> MyResult > It’s conservative and prevents visual ambiguity with e

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

> On Feb 17, 2017, at 11:12 AM, Adrian Zubarev via swift-evolution > wrote: > > Is the throwing type always a protocol? In your example it is, but is this > going to be always the case? > I think right now, there’s a bit of compiler magic in that you can only throw something that conforms to

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

> On Feb 17, 2017, at 11:25 AM, Vladimir.S wrote: > > On 17.02.2017 20:16, David Sweeris via swift-evolution wrote: >> >> >> >> Sent from my iPhone >>> On Feb 17, 2017, at 01:02, Rien wrote: >>> >>> >>>>

Re: [swift-evolution] [swift-evolution-announce] [Re-Review] SE-0104: Protocol-oriented integers

Sent from my iPhone > On Feb 17, 2017, at 17:45, Joe Groff wrote: > >• What is your evaluation of the proposal? Overall, a big +1 I'll 2nd not deprecating the BitwiseOperations protocol, though. >• Is the problem being addressed significant enough to warrant a change to > Swift? Yes

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

> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution > wrote: > > ## Source compatibility > > This proposal breaks source compatibility, but in a way that allows for a > simple mechanical migration. A multi-release stratgegy will be used to roll > out this proposal to provide

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

> On Feb 18, 2017, at 13:12, Matthew Johnson wrote: > > >> On Feb 18, 2017, at 3:01 PM, David Sweeris wrote: >> >> >>> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> ## Source compatibility >>> >>> This proposal breaks source compatibility, but in a

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

> On Feb 18, 2017, at 14:28, Matthew Johnson wrote: > > >> On Feb 18, 2017, at 3:52 PM, David Sweeris wrote: >> >> >>> On Feb 18, 2017, at 13:12, Matthew Johnson wrote: >>> >>> On Feb 18, 2017, at 3:01 PM, David Sweeris wrote: > On Feb 18, 2017, at 12:41 PM, Matthew

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 19, 2017, at 11:47, Michel Fortin via swift-evolution > wrote: > > 7. Is it desirable that the optimizer sometime take the pure attribute to > heart to combine multiple apparently redundant calls into a single one? Or is > pure not intended to be usable for compiler optimizations? Th

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

Sent from my iPhone > On Feb 19, 2017, at 13:41, Lane Schwartz via swift-users > wrote: > > Hi all, > > I'm sure there are good reasons for this switch. Personally, I strongly > prefer email lists to forums. > > This move will make it harder for me to participate in future discussions and

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 19, 2017, at 21:19, Xiaodi Wu wrote: > > This is very, very interesting. Thank you so much for the text. > > If I understand your take correctly, the benefits of `pure` in Swift would be > contingent on how pervasively it can be used (as it's the composability of > pure functions tha

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 10:42 AM, Charles Srstka via swift-evolution > wrote: > >> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> a) Structs/Locals: >> Structs and local variables behave similarly. You can access `let` and `var

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 11:23 AM, Charles Srstka via swift-evolution > wrote: > >> On Feb 20, 2017, at 12:53 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >

Re: [swift-evolution] Compile-time generic specialization

> On Feb 20, 2017, at 12:23, Abe Schneider via swift-evolution > wrote: > > However, if I define an operation to on the Tensor: > > class SomeOp { > typealias StorageType = S > var output:Tensor > > init() { > output = Tensor(size: 10) > } > > func apply()

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 2:50 PM, Michel Fortin via swift-evolution > wrote: > >> Le 20 févr. 2017 à 14:45, Matthew Johnson a écrit : >> >>> >>> On Feb 20, 2017, at 1:42 PM, Michel Fortin wrote: >>> Le 20 févr. 2017 à 14:23, Charles Srstka a écrit : I’m not sure how I f

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 09:03, T.J. Usiyan via swift-evolution > wrote: > > # Pure Functions > > * Proposal: > [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md) > * Author(s): [TJ Usiyan](https://github.com/griotspeak) > * Status: **Awaiting review** > * Rev

Re: [swift-evolution] [swift-evolution-announce] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 21, 2017, at 20:46, Xiaodi Wu via swift-evolution > wrote: > > Sign, perhaps, can be thought of as "part of a number," but signum refers to > the signum function (http://en.wikipedia.org/wiki/Sign_function) defined as: > > -1 if x < 0 > 0 if x = 0 > 1 if x > 0 > > 1 isn't really "pa

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 22, 2017, at 8:01 AM, Ben Cohen via swift-evolution > wrote: > > There is another option to avoid the extra types, which is to stop trying to > force the disambiguation through argument labels, accept an ambiguous call > and have the context disambiguate: > > // compilation error: a

Re: [swift-evolution] Overloading Generic Types

> On Dec 23, 2016, at 3:28 PM, David Sweeris via swift-evolution > wrote: > > >> On Dec 23, 2016, at 2:02 PM, Xiaodi Wu > <mailto:xiaodi...@gmail.com>> wrote: >> >> I don't currently have a use for it, but I can certainly see how this might >

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution > wrote: > > I like this idea. I think you made the right choice of syntax given the > alternatives considered. To me `foo(_)` and `foo(:)` equally imply presence > of an argument. The former looks like an anonymous (unname

Re: [swift-evolution] [swift-evolution-announce] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 22, 2017, at 10:39 AM, Max Moiseev wrote: > > Free functions are much less discoverable. Think about the code completion, > for example. > >> On Feb 22, 2017, at 6:01 AM, David Sweeris > > wrote: >> >> >> On Feb 21, 2017, at 20:46, Xiaodi Wu via swift-evo

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

> On Feb 22, 2017, at 10:16 AM, Nate Cook via swift-evolution > wrote: > > Hello all, > > I was surprised to find that I can't use an instance member as the default > value of a method parameter, only constants and the run-time calculated > #file, #line, etc. Is it possible to remove this li

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 22, 2017, at 11:05 AM, Matthew Johnson wrote: > > >> On Feb 22, 2017, at 12:30 PM, David Sweeris wrote: >> >> >>> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> I like this idea. I think you made the right choice of syntax given the >>> alte

Re: [swift-evolution] Overloading Generic Types

> On Feb 22, 2017, at 12:21 PM, Huon Wilson wrote: > > >> On Feb 22, 2017, at 10:20, David Sweeris via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> What if we extended that to any type that’s ExpressibleByNilLiteral & >&

Re: [swift-evolution] Overloading Generic Types

> On Feb 22, 2017, at 1:22 PM, David Sweeris wrote: > >> >> On Feb 22, 2017, at 12:21 PM, Huon Wilson > <mailto:h...@apple.com>> wrote: >> >> >>> On Feb 22, 2017, at 10:20, David Sweeris via swift-evolution >>> mailto:swift-evolu

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 22, 2017, at 12:27 PM, Jacob Bandes-Storch wrote: > > Just to throw out some other options: foo(#) and foo(@). > > (And you thought we'd gotten rid of # argument labels! 😉) Between the two, I’d prefer “foo(#)”, but I don’t think either are very intuitive. - Dave Sweeris ___

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 22, 2017, at 1:59 PM, David Sweeris via swift-evolution > wrote: > > >> On Feb 22, 2017, at 12:27 PM, Jacob Bandes-Storch wrote: >> >> Just to throw out some other options: foo(#) and foo(@). >> >> (And you thought we'd gotten rid

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 22, 2017, at 2:12 PM, Richard Wei wrote: > > In addition, I think # and @ are very confusing since they are not one of the > existing symbols in function name syntax. Agreed, but it seems like every suggestion other than “foo(:)” which doesn’t use such a character ends up potentially

Re: [swift-evolution] Overloading Generic Types

> On Feb 22, 2017, at 3:00 PM, Slava Pestov wrote: > > >> On Dec 23, 2016, at 12:32 PM, David Sweeris via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> (I feel like I’ve already written this... I looked through my sent mail and &

Re: [swift-evolution] Overloading Generic Types

> On Feb 22, 2017, at 3:42 PM, Slava Pestov wrote: > >> On Feb 22, 2017, at 3:39 PM, David Sweeris > > wrote: >> >> Fair enough. Is there a stage 3, or does that mean “out of scope until Swift >> 4.1+”? > > The latter. K - Dave Sweeris

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 07:33, plx via swift-evolution > wrote: > > Next quibble: `Magnitude` being defined as the “absolute value” of the > underlying type seems a bit nonsensical if e.g. `Number` is intended to be > adoptable by complex numbers (let alone quaternions, matrices, and whatnot).

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 23, 2017, at 06:49, Xiaodi Wu via swift-evolution > wrote: > > Nice. That works well. >> On Thu, Feb 23, 2017 at 08:36 Ben Rimmington wrote: >> >> > On 23 Feb 2017, at 14:23, Xiaodi Wu wrote: >> > >> > What happens when you need the backticks for the function name itself? We >> > ca

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution > wrote: > > Are there Number types which can’t be Comparable? >>> >>> Complex numbers. I believe `Number` is designed to allow a complex number >>> type to conform. >>> > > Magnitude could be comparable then. For vec

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 9:54 AM, Karl Wagner wrote: > > >> On 23 Feb 2017, at 18:40, David Sweeris > > wrote: >> >> >> On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> > > Are there Number type

Re: [swift-evolution] [Pitch] CRTP in Swift

> On Feb 23, 2017, at 10:54 AM, Adrian Zubarev via swift-evolution > wrote: > > First of all, writing CRTP is already allowed in Swift, however it doesn’t > work at all. > > For example one would assume that the output of the following code sample > might look like this 1 2 3 4: > > print(

Re: [swift-evolution] Strings in Swift 4

> On Feb 23, 2017, at 4:04 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > >> On 23 Feb 2017, at 02:24, Dave Abrahams > > wrote: >> >> Equally a non-starter. All known threadsafe schemes that require caches to >> be updated upon non-mutating operations ha

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Sent from my iPhone > On Feb 23, 2017, at 10:40, Max Moiseev wrote: > > Conformance to Comparable is not required by anything in the standard library. That surprises me. Isn't there a sort function or something, or did we change it so they all need a predicate now? > I would argue that addi

Re: [swift-evolution] Strings in Swift 4

> On Feb 24, 2017, at 13:41, Ted F.A. van Gaalen wrote: > > Hi David & Dave > > can you explain that in more detail? >>> Wouldn’t that turn simple character access into a mutating function? > > assigning like s[11…14] = str is of course, yes. > only then - that is if the character array thu

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 2:33 PM, Karl Wagner wrote: > > >> On 23 Feb 2017, at 19:40, Max Moiseev wrote: >> >> Conformance to Comparable is not required by anything in the standard >> library. Besides, it is always possible to further constrain your own code >> as in: >> > > Besides Floating

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 14:44, David Sweeris wrote: > > >>> On Feb 23, 2017, at 2:33 PM, Karl Wagner wrote: >>> >>> >>> On 23 Feb 2017, at 19:40, Max Moiseev wrote: >>> >>> Conformance to Comparable is not required by anything in the standard >>> library. Besides, it is always possible to f

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

which would be > incorrect uses. This was borne out by observation of erroneous uses of > floating point % in Swift 2. > On Fri, Feb 24, 2017 at 18:13 David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > On Feb 23, 2017, at 14:44, David Sweer

Re: [swift-evolution] 'T != Type' in where clause

Sent from my iPhone > On Feb 27, 2017, at 16:34, Rex Fenley via swift-evolution > wrote: > > I often find myself running into situations where I'll receive "Ambiguous use > of..." for overloaded functions or operators. In every case these situations > would be easily solved if I could speci

Re: [swift-evolution] 'T != Type' in where clause

> On Feb 28, 2017, at 09:38, Adrian Zubarev via swift-evolution > wrote: > > I also thought about the Either type. > > enum Either where A != B { > case -> A > case -> B > } I was thinking about using it as a workaround for not having typed throws: protocol MyErrorType: Error {...} //

Re: [swift-evolution] 'T != Type' in where clause

> On Feb 28, 2017, at 09:01, Joe Groff wrote: > > >> On Feb 27, 2017, at 10:21 PM, David Sweeris via swift-evolution >> wrote: >> >> + all the 1s, along with something like "where !(T: Foo)" > > This is an impossible constraint to enforce,

Re: [swift-evolution] 'T != Type' in where clause

> On Mar 1, 2017, at 18:55, Joe Groff wrote: > > >> On Mar 1, 2017, at 5:27 PM, David Sweeris wrote: >> >> >>> On Feb 28, 2017, at 09:01, Joe Groff wrote: >>> >>> >>>> On Feb 27, 2017, at 10:21 PM, David Sweeris via

Re: [swift-evolution] [Accepted] SE-0104: Protocol-oriented integers

> On Mar 2, 2017, at 06:22, Björn Forster via swift-evolution > wrote: > > Hello Joe, > I wanted to ask kindly if it would be possible that the core team adds to the > rationale the design decision behind > associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral > being not compar

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0157: Support recursive constraints on associated types

On Feb 28, 2017, at 13:40, John McCall mailto:rjmcc...@apple.com>> wrote: > Hello Swift community, > > The review of SE-0157 "Support recursive constraints on associated types" > begins now and runs through next Wednesday, March 8, 2017. The proposal is > available here: > > https://github.co

[swift-evolution] Custom Literals

The conversation kinda died out over the new year, and a quick search didn’t come up with an answer... Did we decide that adding user-definable literal types was out of scope for Swift 4? - Dave Sweeris ___ swift-evolution mailing list swift-evolution@

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

> On Mar 7, 2017, at 12:53 PM, Rick Ballard via swift-build-dev > wrote: > > Hello Swift community, > > The review of "SE-0158 Package Manager Manifest API Redesign" begins now and > runs through March 13, 2017. The proposal is available here: > > > https://github.com/apple/swift-evol

<    1   2   3   4   5   6   >