Re: [swift-evolution] Compile time assertion / checking?

, 2015, at 8:16 AM, Jens Persson via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Sorry if this has been asked before (searched but couldn't find > anything). > > I'll explain what I mean by an example of a situation where I think it > would be reaso

[swift-evolution] Fix or remove Swift.min and Swift.max?

Hi all! Swift.min (and Swift.max) propagates nan or not depending on the order of its args: Swift.min(1.0, .nan) // 1.0 Swift.min(.nan, 1.0) // nan (!) Double.minimum(1.0, .nan) // 1.0 Double.minimum(.nan, 1.0) // 1.0 fmin(1.0, .nan) // 1.0 fmin(.nan, 1.0) // 1.0 The new static minimum and

[swift-evolution] [Discussion] Parentheses

Please feel free to ignore this naive attempt to engage in this discussion. My understanding of the history of Swift's tuples, argument lists, pattern matching, associated values, etc. in two steps: 1. Initial Idealism *: Simple powerful heavily reused general concept. 2. Iterative pragmatism /

Re: [swift-evolution] [Discussion] Parentheses

a >> lot simpler.) >> >> ... Well, I think you get the idea. >> >> I'm wondering if there has been any attempts at such from-the-scratch >> redesigns of all these parentheses-related-things in the language >> (including eg pattern ma

Re: [swift-evolution] [Discussion] Parentheses

Int, Int ⊃ -> Int // Function type from a 3-Int-tuple to an Int. >>> ⊂⊂ Int, Int, Int ⊃⊃ -> Int // Function type from a single element tuple >>> whose element is a 3-Int-tuple to an Int. (Yes, nobody would probably >>> write >>> a function of such a type, bu

Re: [swift-evolution] [Discussion] Parentheses

ypes to variables without 'self', the > following would be ambiguous: > > Optional(0).map { _ in return (((Int))) } > > Do parentheses belong to type or to value? Currently it does not really > matter, but with the change it would. > > 2016-07-07 22:16 GMT+03:00 Jens Persson v

Re: [swift-evolution] [Discussion] Parentheses

6, 2016, at 7:47 AM, Vladimir.S via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>> On 06.07.2016 3:57, Jens Persson via swift-evolution wrote: >>> >>>> Please feel free to ignore this naive attempt to engage in this

Re: [swift-evolution] generic associatedtype?

lve into a [String], ie the lines of code which will replace the content of the PRINT-block. /Jens On Tue, Sep 20, 2016 at 4:34 PM, Vladimir.S <sva...@gmail.com> wrote: > On 20.09.2016 16:43, Jens Persson via swift-evolution wrote: > >> Sure, but the reason to go for C++ in this case wou

Re: [swift-evolution] generic associatedtype?

can be any expression that resolve >> into a [String], ie the lines of code which will replace the content of the >> PRINT-block. >> >> /Jens >> >> >> On Tue, Sep 20, 2016 at 4:34 PM, Vladimir.S <sva...@gmail.com> wrote: >> >>> On 20.09.2016 16:43, Je

Re: [swift-evolution] generic associatedtype?

olve > into a [String], ie the lines of code which will replace the content of the > PRINT-block. > > /Jens > > > On Tue, Sep 20, 2016 at 4:34 PM, Vladimir.S <sva...@gmail.com> wrote: > >> On 20.09.2016 16:43, Jens Persson via swift-evolution wrote: >> >

[swift-evolution] generic associatedtype?

Has there been any discussions about the possibility of having generic associatedtypes? I (naively) think that it would open up a lot of possibilities. Because if, for example, we could do this: protocol CountType { associatedtype Storage ... } Then we could do this: struct Count1 :

Re: [swift-evolution] generic associatedtype?

on IMHO and should be expanded and > not begrudged. > > Sent from my iPhone > > On 19 Sep 2016, at 14:14, Jens Persson via swift-evolution < > swift-evolution@swift.org> wrote: > > Ok, thanks! I take it that we should not expect any dramatic advances of > Swift's type sy

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

I've used code like the following example in similar situations and I've always (after a lot of profiling, trial and error) managed to get the (ugly) Swift code as fast as the C/C++ code. struct UnsafeStatic19x19 { var storage: ( E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,

Re: [swift-evolution] [Pitch] BitPatternRepresentable

On Wed, Jul 12, 2017 at 12:23 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > /../ > As ever, my first question when a new protocol is proposed is, “what > generic algorithms rely on this protocol?” > > First, please note that I made some mistakes in the code earlier

Re: [swift-evolution] [Pitch] BitPatternRepresentable

Oh, I forgot the signed IntN types: extension Int8 : BitPatternRepresentable { var bitPattern: UInt8 { return UInt8(bitPattern: self) } init(bitPattern: UInt8) { self = Int8(bitPattern: bitPattern) } } extension Int16 : BitPatternRepresentable { var bitPattern: UInt16 { return

[swift-evolution] [Pitch] BitPatternRepresentable

I've found it practical/necessary to write my own BitPatternRepresentable protocol and IMHO it feels like something that could have been added along with the improved numeric protocols of Swift 4. Would it make sense to add something like the following to the standard library? /// A type that

Re: [swift-evolution] [Proposal] Introduces endianness specific type

ut control (since being able to define structs to be used for low level data manipulation is important in a systems language). /Jens On Sun, Jul 9, 2017 at 7:01 PM, Jens Persson via swift-evolution < swift-evolution@swift.org> wrote: > I should perhaps add that in my image processing co

Re: [swift-evolution] [Proposal] Introduces endianness specific type

, at 4:49 PM, Jens Persson via swift-evolution < > swift-evolution@swift.org> wrote: > > Sorry for making so much off topic noise in this thread, but I made a > mistake regarding the Metal tutorial: > Looking more carefully I see now that they rebuild a vertedData: [Float] >

Re: [swift-evolution] [Proposal] Introduces endianness specific type

I should perhaps add that in my image processing code, I use code like this: func withVImageBuffer(for table: Table, body: (vImage_Buffer) -> R) -> R where Data.Coordinate.Index == VectorIndex2 { let vib = vImage_Buffer( data: table.baseAddress, height:

Re: [swift-evolution] [Proposal] Introduces endianness specific type

I don't think I'm misunderstanding you, but I might be, so I'll add more detail: If you look at the Metal article, you'll see that the (Swift) struct "Vertex" is used to specify the data that is sent to Metal for creating a buffer (using MTLDevice.makeBuffer). The result that the GPU will produce

Re: [swift-evolution] [Proposal] Introduces endianness specific type

On Sat, Jul 8, 2017 at 6:28 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hi Susan, > > Swift does not currently specify a layout for Swift structs. You > shouldn’t be using them for memory mapped i/o or writing to a file, because > their layout can change. When

[swift-evolution] Request for information about constrained protocol inheritance

The following compiles in Swift 4 (but not in Swift 3.1): protocol P1 { associatedtype A } protocol P2 : P1 where A == Int { } I've not been able to find any proposal, discussion or documentation mentioning it so any pointers to such would be greatly appreciated. Also, is this new feature

[swift-evolution] Intended behavior of typealiases in extensions?

Typealiases in extensions currently does not work as expected or intended, as can be demonstrated by the following example: struct S { var hmm: (A, B, C) } extension S where A == Bool { typealias B = A static func printB() { print(B.self) } } extension S where A == Float {

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

quot;messy," and what kinds of > cleaning up are you seeking to discuss? > > > > On Fri, Jun 9, 2017 at 7:34 PM, Jens Persson via swift-evolution < > swift-evolution@swift.org> wrote: > >> The analogy of the special first parameter label was relevant (for me) in &g

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

The point of exercise 1 is to show that it is impossible (in Swift 4) to write a generic function composition operator (or function) which works as expected for any reasonable functions. This was possible in Swift 3, but in Swift 4 it will only work for functions with exactly one parameter. You'd

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

to be done before ABI stability. Please correct/enlighten me! /Jens On Sat, Jun 10, 2017 at 12:50 AM, Michael Ilseman <milse...@apple.com> wrote: > > > On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution < > swift-evolution@swift.org> wrote: > > The

Re: [swift-evolution] [Proposal] Change Void meaning

I have just had a quick look but I'm interested in what you think about the following example, which currently behaves like the comments say: func foo(_ fn: (A) -> Void) {} func fnA() {} func fnB(_ a: Int) {} func fnC(_ a: Int, _ b: Int) {} foo(fnA) // Compiles in Swift 3, error in Swift 4

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

Ok, I understand, thanks! On Mon, Jun 12, 2017 at 9:29 PM, John McCall wrote: > On Jun 12, 2017, at 3:13 PM, Jens Persson wrote: > On Mon, Jun 12, 2017 at 8:52 PM, John McCall wrote: >> >> >> We really do want to tie most of these

Re: [swift-evolution] [Proposal] Change Void meaning

Yes, I agree and I think the behavior of Swift 4 is more consistent than that of Swift 3(.2) here. On Mon, Jun 12, 2017 at 9:57 PM, Xiaodi Wu wrote: > On Mon, Jun 12, 2017 at 2:49 PM, Jens Persson wrote: > >> Just adding this here for reference: >> func

Re: [swift-evolution] [Proposal] Change Void meaning

I think this proposal would be complicating rather than simplifying the type system, it would be adding a special rule. And it is not a step towards resolving the many parentheses-related inconsistencies that still remain. Here is an example of one such remaining inconsistency, it's still in

Re: [swift-evolution] [Proposal] Change Void meaning

This: https://twitter.com/slava_pestov/status/874394132340289536 seems to suggest that the current Swift 4 behavior will not change much in this domain. On Tue, Jun 13, 2017 at 1:11 AM, Vladimir.S <sva...@gmail.com> wrote: > On 12.06.2017 23:17, Jens Persson via swift-evolution wrot

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

On Mon, Jun 12, 2017 at 7:13 PM, Michael Ilseman wrote: > > > * Unless you’re proposing a change to the semantics of the language that > could affect e.g. name mangling or the type metadata hierarchy, then that > would be ABI-affecting. For example, proposing that all

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

On Mon, Jun 12, 2017 at 8:52 PM, John McCall wrote: > > > We really do want to tie most of these features specifically to function > calls. > I'm not sure if I understand what you mean. Do you mean that you really don't want these features to require changes to the type

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

Yes of course, try my demonstration code yourself. (In the current dev snapshots, -swift-version 4 is the default and -swift-version 3 is what you need to set if you want 3 compability) On Sun, Jun 4, 2017 at 12:37 AM, Ben Rimmington wrote: > Are you using the Swift 4

[swift-evolution] Why is the status of SE-0110 "implemented"?

I was notified that my SR-2216 and SR-296 had been "fixed as part of implementing SE-0110". But AFAICT SE-0110 can't possibly be fully implemented in dev snapshot 2017-06-02, even though the status of SE-0110 is "Implemented (Swift 4)". The title of SE-0110 is "Distinguish between single-tuple

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

Swift uses parentheses for a lot of different things (tuples, parameters, calls, grouping, pattern matching, etc), this has led to some confusion, for both language designers and users. Here's a practical introduction that is possibly worth more than a thousand words (or perhaps even swift-evo

Re: [swift-evolution] Proposal: Always flatten the single element tuple

I just want to say, as a "regular developer", that I'm with Vladimir S here. Swift 3 (and current Swift 4) both still have a lot of inconsistencies and/or bugs related to tuple- and function types which will need to be fixed before ABI stability, and they are not fixed by going back to a state

Re: [swift-evolution] Proposal: Always flatten the single element tuple

On Thu, Jun 8, 2017 at 7:20 PM, Víctor Pimentel Rodríguez via swift-evolution wrote: > > /../ I'm really going to miss being able to model every type of closure > with the type (T) -> U > Me too, and I can also see what you mean regarding the "tone" of some of the

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

t; Int. I don't think that is a dynamic cast, is it? /Jens On Tue, Jun 6, 2017 at 2:45 AM, John McCall <rjmcc...@apple.com> wrote: > On Jun 5, 2017, at 12:08 AM, Jens Persson via swift-evolution < > swift-evolution@swift.org> wrote: > So the bug in the reflective type syst

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

So the bug in the reflective type system needs to be fixed before SE-0110 can actually be implemented (so that the statements in its title and text are true when compared to the actual behavior of the current Swift 4 compiler), And yet: 1. The status of SE-0110 is "Implemented" 2. These

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

losureParam is (_: (Int,Int))->() > >>> > >>> if closureTuple is (Int,Int)->() { print("closureTuple is > (Int,Int)->()") } > >>> // result: closureTuple is (Int,Int)->() > >> Can you open two reports at bugs.swift.org <htt

Re: [swift-evolution] [Proposal] Change Void meaning

The std lib swap could perhaps be an interesting example to consider: public func swap(_ a: inout T, _ b: inout T) What would happen with that? Will inout arguments be an exception to the rule of Void getting a default value, and if so, what would the effects of that be? Or would it somehow be

Re: [swift-evolution] [Proposal] Change Void meaning

Ah, right! On Tue, Jun 13, 2017 at 7:40 PM, Xiaodi Wu wrote: > Note that “inout Void” is a distinct type from “Void”; it is not possible > to specify a default value for an inout Void parameter even explicitly > (“error: cannot pass immutable value of type ()...”), so

Re: [swift-evolution] [RFC] Associated type inference

Would this help sorting out the behavior of typealiases in constrained extensions? If not, please ignore the following and accept my apologies for posting OT. Typealiases in constrained extensions are - and have been, for a long time - very broken. The following program (which is clearly crazy

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

I'd like to add a pointer to the information here: http://xoroshiro.di.unimi.it since AFAICS, the xoroshiro128+ generator and the method of "Generating uniform doubles in the unit interval" should probably be implemented in any modern general purpose Random API. Please correct me if there are

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

; the proposal outlines sources of randomness that are cryptographically > secure. > > > > On Wed, Dec 20, 2017 at 09:46 Jens Persson via swift-evolution < > swift-evolution@swift.org> wrote: > >> I'd like to add a pointer to the information here: >> http://

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

On Tue, Jan 9, 2018 at 10:07 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > > One additional question. How do you ergonomically get a Double which > doesn’t have a range, but also isn’t NaN? > > Assuming you are ok with signed zero and infinities and "strange" bias

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

t by the last part of: "Assuming you are ok with signed zero and infinities and "strange" bias as result of IEEE 754" Also, I think it's impossible to get a uniform distribution of all non-Nan Double values (since they include +- infinity). /Jens > Saagar Jha > > On

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

t; Yes, it would not be uniform, which is exactly what I meant by the last > part of: "Assuming you are ok with signed zero and infinities and > "strange" bias as result of IEEE 754" > > Also, I think it's impossible to get a uniform distribution of all non-Nan >