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

[Jens Persson via swift-evolution]

I agree.

If there should be an API to produce a random Double without parameters
then IMHO it should simply be a uniformly distributed Double in the unit
range [0, 1). Very useful as a basic building block and can be constructed
very fast from a random bitpattern like eg:
extension Double {
init(unitRange v: UInt64) {
self = Double(v >> Double.exponentBitCount) * (.ulpOfOne/2.0)
}
}



On Wed, Jan 10, 2018 at 11:48 PM, Saagar Jha  wrote:

> Which begs the question: why would you want to do something like this?
> Creating a “random” Double from its full range of values is an odd thing to
> do, and the fact that it is non-uniform and has irregularities like
> infinity and signed zeros makes it likely that any such usage is probably
> done in error (the one reason I can think of is if you’re trying to test
> your code with random Doubles, but I’d argue for keeping NaN in that case).
> Generally users are looking for uniform distributions or ones that follow
> some set pattern (e.g. normal, Bernoulli), so this doesn’t seem useful at
> all.
>
> Saagar Jha
>
> On Jan 10, 2018, at 14:39, Jens Persson  wrote:
>
> On Wed, Jan 10, 2018 at 11:27 PM, Saagar Jha  wrote:
>
>> Not a floating point expert, but are you sure this works? I have a
>> feeling this would lead to a distribution that’s not uniform.
>>
>>
> 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
> Double values (since they include +- infinity).
>
> /Jens
>
>
>
>> Saagar Jha
>>
>> On Jan 10, 2018, at 14:07, Jens Persson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> 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 as
>> result of IEEE 754:
>>
>> func randomNonNanDouble(using generator: R) ->
>> Double {
>> while true {
>> let rndUInt64 = generator.next()
>> let rndDouble = Double(bitPattern: rndUInt64)
>> if rndDouble != Double.nan { return rndDouble }
>> }
>> }
>>
>> /Jens
>>
>> ___
>> 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] [Proposal] Random Unification

[Jens Persson via swift-evolution]

On Wed, Jan 10, 2018 at 11:27 PM, Saagar Jha  wrote:

> Not a floating point expert, but are you sure this works? I have a feeling
> this would lead to a distribution that’s not uniform.
>
>
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
Double values (since they include +- infinity).

/Jens



> Saagar Jha
>
> On Jan 10, 2018, at 14:07, Jens Persson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 as
> result of IEEE 754:
>
> func randomNonNanDouble(using generator: R) ->
> Double {
> while true {
> let rndUInt64 = generator.next()
> let rndDouble = Double(bitPattern: rndUInt64)
> if rndDouble != Double.nan { return rndDouble }
> }
> }
>
> /Jens
>
> ___
> 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] [Proposal] Random Unification

[Jens Persson via swift-evolution]

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 as
result of IEEE 754:

func randomNonNanDouble(using generator: R) ->
Double {
while true {
let rndUInt64 = generator.next()
let rndDouble = Double(bitPattern: rndUInt64)
if rndDouble != Double.nan { return rndDouble }
}
}

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

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

[Jens Persson via swift-evolution]

Oh OK, I must have misunderstood this thread:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042034.html
(
"The strong opinion of the core team is that such an API should *not* be
designed with an attempt to service people writing crypto code."
"It is general goodness if generality for crypto use cases somehow falls
out of the design.  However, the design for general use shouldn’t suffer
because of that goal."
)

I assumed that the Random API would save the user from the trouble of
making a good choice and implementation (fast and good quality) of a
"standard" general purpose prng (as well as maybe a cryptographically
secure one).

Also, the most commonly recommended ways of converting from eg 64 random
bits to an int range or a floating point range are unnecessarily bad and
slow, so I figured the webpage was worth a read, in addition to C++
stdlib's implementation.

/Jens


On Wed, Dec 20, 2017 at 4:55 PM, Xiaodi Wu  wrote:

> xoroshiro128+ is not a cryptographically secure algorithm and would not be
> incorporated into the Random API, though it is trivial to implement your
> own; 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://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 more up to date (higher quality and
>> faster) general purpose generators and ways of converting UInt64 bit
>> patterns to floating point [0, 1).
>>
>> /Jens
>>
>>
>>
>> On Sun, Dec 3, 2017 at 4:50 AM, Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I don’t have much to say about this other than that I think the
>>> discussion seems way too narrow, focusing on spelling rather than on
>>> functionality and composability.  I consider the “generic random number
>>> library” design to be a mostly-solved problem, in the C++ standard
>>> library (http://en.cppreference.com/w/cpp/numeric/random).  Whatever
>>> goes into the Swift standard library does not need to have all those
>>> features right away, but should support being extended into something
>>> having the same general shape. IMO the right design strategy is to 
>>> *implement
>>> and use* a Swift version of C++’s facilities and only then consider
>>> proposing [perhaps a subset of] that design for standardization in Swift.
>>>
>>> Sent from my iPad
>>>
>>> On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Instead, we ought to make clear to users both the features and the
>>> limitations of this API, to encourage use where suitable and to discourage
>>> use where unsuitable.
>>>
>>>
>>> I like that you're considering the balance here. I've been lightly
>>> following this thread and want to add my thoughts on keeping crypto and
>>> pseudorandomness out of the name of at least one random API intended
>>> for general use.
>>>
>>> For someone who doesn't know or care about the subtleties of insecure or
>>> pseudorandom numbers, I'm not sure that the name insecureRandom is
>>> effectively much different than badRandom, at least in terms of the
>>> information it conveys to non-experts. To Greg's point, that's the opposite
>>> of the signal that the API name should suggest because it's what most
>>> people should use most of the time. As you say, this API is being designed
>>> for general use.
>>>
>>> There's a cost to adding extra complexity to names, too. I don't think
>>> it's far-fetched to suspect that people who find insecureRandom in an
>>> autocomplete listing or search will think "Where's the plain random
>>> function?"... and then go looking for a community extension that will
>>> inevitably provide a trivial alias: func random() { return
>>> insecureRandom() }. That's the sort of adoption I'd expect from
>>> something for new programmers, like Swift Playgrounds. S

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

[Jens Persson via swift-evolution]

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 more up to date (higher quality and faster)
general purpose generators and ways of converting UInt64 bit patterns to
floating point [0, 1).

/Jens



On Sun, Dec 3, 2017 at 4:50 AM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

> I don’t have much to say about this other than that I think the discussion
> seems way too narrow, focusing on spelling rather than on functionality and
> composability.  I consider the “generic random number library” design to be
> a mostly-solved problem, in the C++ standard library (
> http://en.cppreference.com/w/cpp/numeric/random).  Whatever goes into the
> Swift standard library does not need to have all those features right away,
> but should support being extended into something having the same general
> shape. IMO the right design strategy is to *implement and use* a Swift
> version of C++’s facilities and only then consider proposing [perhaps a
> subset of] that design for standardization in Swift.
>
> Sent from my iPad
>
> On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Instead, we ought to make clear to users both the features and the
> limitations of this API, to encourage use where suitable and to discourage
> use where unsuitable.
>
>
> I like that you're considering the balance here. I've been lightly
> following this thread and want to add my thoughts on keeping crypto and
> pseudorandomness out of the name of at least one random API intended for
> general use.
>
> For someone who doesn't know or care about the subtleties of insecure or
> pseudorandom numbers, I'm not sure that the name insecureRandom is
> effectively much different than badRandom, at least in terms of the
> information it conveys to non-experts. To Greg's point, that's the opposite
> of the signal that the API name should suggest because it's what most
> people should use most of the time. As you say, this API is being designed
> for general use.
>
> There's a cost to adding extra complexity to names, too. I don't think
> it's far-fetched to suspect that people who find insecureRandom in an
> autocomplete listing or search will think "Where's the plain random
> function?"... and then go looking for a community extension that will
> inevitably provide a trivial alias: func random() { return
> insecureRandom() }. That's the sort of adoption I'd expect from something
> for new programmers, like Swift Playgrounds. Someone's introduction to
> randomness in programming should probably involve no more than a
> straightforward mapping from the elementary definition, rather than forcing
> a teaching moment from more advanced math.
>
> I think there are better places for caveat information than in the API
> names themselves; documentation being one clear destination. This is in
> contrast with Unsafe*Pointer, where the safety element is critical enough
> to be elevated to be more than caveat-level information. You can go really
> far and create really cool things before these caveats start to apply.
> Using randomness as a black box in an intro programming environment seems
> like a much more common scenario than someone attempting to roll their
> first crypto by only reading API names and hoping for the best.
>
> -Kyle
>
> ___
> 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] [RFC] Associated type inference

[Jens Persson via swift-evolution]

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 in several ways) compiles and
runs using the latest version of the compiler:

struct S {
  var v: This
}
extension S where T == Int {
  typealias This = Is
}
extension S where T == Bool {
  typealias Is = Fine
}
extension S where T == String {
  typealias Fine = T
}
let x = S(v: "uh")
print(x.v) // uh

( SR-5440 )
The current behavior is so allowing and strange that I'm having trouble
seeing what the correct behavior would be if things worked as intended.
For example should the following program still compile, and if so, should
the last line also compile (if uncommented)?

protocol P {
associatedtype A = Int
associatedtype B = Bool
typealias C = Float
}
extension P where B == A {
typealias C = String
}
struct S : P {
var v: (A, B, C)
}
extension S where A == Int, B == Bool {
typealias C = [String]
}
let s1 = S(v: (1, true, [""]))
// let s2 = S(v: ("a", "b", "c")) // Not (currently) ok.

Again, sorry for the noise if this is unrelated to the discussion.
/Jens


On Sun, Dec 3, 2017 at 6:23 AM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Nov 30, 2017, at 2:28 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello Swift community,
>
> Associated type inference, which is the process by which the Swift
> compiler attempts to infer typealiases to satisfy associated-type
> requirements based on other requirements, has caused both implementation
> problems and user confusion for a long time. Some of you might remember a
> previous (failed) attempt to remove this feature from the Swift language,
> in SE-0108 “Remove associated type inference”.
> 
>
>
> I’m not sure we can remove this feature outright (i.e., the concerns that
> sank that proposal are still absolutely valid), because it is so very
> convenient and a lot of user code likely depends on it in some form or
> other. So, here I’d like to describe the uses of the feature, its current
> (very problematic) implementation approach, and a half-baked proposal to
> narrow the scope of associated type inference to something that I think is
> more tractable. I need help with the design of this feature, because I feel
> like it’s going to be a delicate balance between implementability and
> expressiveness.
>
>
> Aloha, Doug!
>
>
> *A Motivating Example*
> As a motivating example, let’s consider a “minimal” random access
> collection:
>
> struct MyCollection {
> var contents: [T]
> }
>
> extension MyCollection: RandomAccessCollection {
> var startIndex: Int { return contents.startIndex }
> var endIndex: Int { return contents.endIndex }
> subscript(index: Int) -> T { return contents[index] }
> }
>
>
> This is actually pretty awesome: by providing just two properties and a
> subscript, we get the full breadth of the random access collection API!
> This is relying heavily on associated type inference (for associated type
> requirements) and default implementations specified on protocol extensions.
> Without associated type inference, we would have had to write:
>
>
> extension MyCollection: RandomAccessCollection {
> *typealias Element = T*
> *typealias Index = Int*
> *typealias Indices = CountableRange*
> *typealias Iterator = IndexingIterator>*
> *typealias SubSequence = RandomAccessSlice>*
>
> var startIndex: Int { return contents.startIndex }
> var endIndex: Int { return contents.endIndex }
> subscript(index: Int) -> T { return contents[index] }
> }
>
> where the bolded typealiases are currently inferred. It was worse back
> when we reviewed SE-0108, because IIRC there were a few underscored
> associated types (e.g., _Element) that have since been removed. Still,
> that’s a bit of additional work to define a “minimal” collection, and
> requires quite a bit more understanding: how do I know to choose
> IndexingIterator, and CountableRange, and RandomAccessSlice?
>
> The issue would get worse with, e.g., SE-0174 “Change filter to return an
> associated type”
> ,
> which adds an associated type Filtered that almost nobody will ever
> customize, and isn’t really fundamental to the way collections work. Adding
> Filtered to the standard library would be a source-breaking change, because
> users would have to write a typealias giving it its default.
>
> *Associated Type Defaults*
> One of the ways in which we avoid having to specify typealiases is to use
> associated type defaults. For example, the standard library contains
> associated type defaults for

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

[Jens Persson via swift-evolution]

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 {
typealias C = A
static func printC() { print(C.self) }
}
let a = S(hmm: ("strange", true, Float(42.1)))
dump(a)

The above program will compile (!) and print:
▿ VectorAttempt4_Xc9b4.S
  ▿ hmm: (3 elements)
- .0: "strange"
- .1: true
- .2: 42.085

(SR-5440)

Here, the intended behavior would most probably involve a compile time
error for the declaration of `hmm: (A, B, C)`.

But in the following example, it is not that easy to guess the intended
behavior, and so I'd like to ask for your thoughts about it:

protocol P {
associatedtype A
typealias B = Int
}
extension P where A == Bool {
typealias B = Float // Compiles, but should it?
}
extension P where A == Double {
typealias B = String // ERROR: Invalid redeclaration of `B`
}

(SR-5392)

Note that Bool, Int, Float, Double and String can be any types; ie the
topmost overloaded-typealias-in-an-extension will always compile but the
rest will fail.

So, should both compile (thus allow overloading of `B`) or should both be
considered redeclarations?

I (naively) think it would be nice if both compiled, ie if it was possible
to overload associated types in constrained extensions, since it could open
up some interesting possibilities (or perhaps only a can of worms?).

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

Re: [swift-evolution] [Pitch] BitPatternRepresentable

[Jens Persson via swift-evolution]

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 in this
conversation as I did not have a compiler at hand, a better version can be
found in the PS-section of this post:
https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20170710/005921.html

It contains some more context also.

To answer your question: I'm using it as one of the basic building blocks
needed for implementing generic statically allocated Vector types with
type-level Element and Count/Index (despite the current limitations of
Swift's type system!) , more specifically:
...
protocol Vector {
associatedtype Index: VectorIndex
associatedtype Element
init(elementForIndex: (Index) -> Element)
subscript(index: Index) -> Element { get set }
}
...
protocol VectorIndex where
VectorUInt32.Element == UInt32, VectorUInt32.Index == Self, // I guess
this should not work
VectorUInt64.Element == UInt64, VectorUInt64.Index == Self  // but it's
actually a workaround …
{
associatedtype VectorUInt32 : Vector // … for some bug that makes it
necessary to add
associatedtype VectorUInt64 : Vector // the constraints up there
instead of down here ...
...
}
...
enum Index1 : VectorIndex { // Yes, there are situations when we want a
1-element vector.
typealias VectorUInt8 = Vector1
typealias VectorUInt16 = Vector1
typealias VectorUInt32 = Vector1
typealias VectorUInt64 = Vector1
case i0
}
enum Index2 : VectorIndex {
typealias VectorUInt8 = Vector2
typealias VectorUInt16 = Vector2
typealias VectorUInt32 = Vector2
typealias VectorUInt64 = Vector2
case i0, i1
}
enum Index3 : VectorIndex {
typealias VectorUInt8 = Vector3
typealias VectorUInt16 = Vector3
typealias VectorUInt32 = Vector3
typealias VectorUInt64 = Vector3
case i0, i1, i2
}
enum Index4 : VectorIndex {
typealias VectorUInt8 = Vector4
typealias VectorUInt16 = Vector4
typealias VectorUInt32 = Vector4
typealias VectorUInt64 = Vector4
case i0, i1, i2. i3
}
// Add more if needed, I haven't yet needed more than 4.
...
...
// I leave Vector1, Vector3 and Vector4 out since they are obvious given
this:
struct Vector2 : Vector {
typealias Index = Index2
typealias Element = E
var elements: (Element, Element)
init(elementForIndex: (Index) -> Element) {
elements = (elementForIndex(.i0), elementForIndex(.i1))
}
subscript(index: Index) -> Element {
get {
switch index {
case .i0: return elements.0
case .i1: return elements.1
}
}
set {
switch index {
case .i0: elements.0 = newValue
case .i1: elements.1 = newValue
}
}
}
}
...
// This type of Vector is needed for the interesting and hard version of
map in the example below:
struct PrimaryBitPatternBasedVector : Vector where
Base: Vector,
E: PrimaryBitPatternRepresentable,
E.PrimaryBitPattern == Base.Element
{
typealias Index = Base.Index
typealias Element = E
var base: Base
init(elementForIndex: (Index) -> Element) {
base = Base.init { elementForIndex($0).bitPattern }
}
subscript(index: Index) -> Element {
get { return Element(bitPattern: base[index]) }
set { base[index] = newValue.bitPattern }
}
}
...
extension Vector {
...
// It's easy as long as the return type is just Self.
func map(transform: (Element) -> Element) -> Self {
return .init { transform(self[$0]) }
}
// But THIS MAP is an interesting example of something that is very
hard/impossible to accomplish given Swift's current type system, so we need
to special case it in some way, and one way that includes most of the
interesting element types is to do this, which will cover any type whose
values can be represented as a fixed width bit pattern:
func map(transform: (Element) -> ResultingElement) ->
PrimaryBitPatternBasedVector {
return .init { transform(self[$0]) }
}
func map(transform: (Element) -> ResultingElement) ->
PrimaryBitPatternBasedVector {
return .init { transform(self[$0]) }
}
func map(transform: (Element) -> ResultingElement) ->
PrimaryBitPatternBasedVector {
return .init { transform(self[$0]) }
}
func map(transform: (Element) -> ResultingElement) ->
PrimaryBitPatternBasedVector {
return .init { transform(self[$0]) }
}
...
}
...

Phew,
Don't know if that makes any sense when stripped down and edited like that
but I don't feel like posting the entire code because it needs better
naming, cleaning up, etc. first.

But more generally I think that this little protocol
(PrimaryBitPatternRepresentable (but better named)) would just tie 

[swift-evolution] [Pitch] BitPatternRepresentable

[Jens Persson via swift-evolution]

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 can be converted to and from an associated BitPattern type.
protocol BitPatternRepresentable {
associatedtype BitPattern
var bitPattern: BitPattern { get }
init(bitPattern: BitPattern)
}

I think it's preferable to keep the conforming type's BitPatterns to the
most basic (most "BitPattern-like" types) so eg
UInt8, UInt16, UInt32, UInt64
rather than
Int8, Int16, Int32, Int64
and, depending on platform
UInt64, UInt32
rather than
Int or UInt.

PS

// Double and Float already fulfill the requirements of
BitPatternRepresentable so:

extension Double : BitPatternRepresentable {}
extension Float : BitPatternRepresentable {}

// And here is the rest of the types that I've used:

extension UInt8 : BitPatternRepresentable {
var bitPattern: UInt8 { return self }
init(bitPattern: UInt8) { self = bitPattern }
}
extension UInt16 : BitPatternRepresentable {
var bitPattern: UInt16 { return self }
init(bitPattern: UInt16) { self = bitPattern }
}
extension UInt32 : BitPatternRepresentable {
var bitPattern: UInt32 { return self }
init(bitPattern: UInt32) { self = bitPattern }
}
extension UInt64 : BitPatternRepresentable {
var bitPattern: UInt64 { return self }
init(bitPattern: UInt64) { self = bitPattern }
}
#if arch(x86_64) || arch(arm64)
extension Int : BitPatternRepresentable {
var bitPattern: UInt64 { return UInt64(UInt.init(bitPattern: self))
}
init(bitPattern: UInt64) { self = Int(Int64(bitPattern:
bitPattern)) }
}
extension UInt : BitPatternRepresentable {
var bitPattern: UInt64 { return UInt64(self) }
init(bitPattern: UInt64) { self = UInt(bitPattern) }
}
#elseif arch(i386) || arch(arm)
extension Int : BitPatternRepresentable {
var bitPattern: UInt32 { return UInt32(UInt.init(bitPattern: self))
}
init(bitPattern: UInt32) { self = Int(Int32(bitPattern:
bitPattern)) }
}
extension UInt : BitPatternRepresentable {
var bitPattern: UInt32 { return UInt32(self) }
init(bitPattern: UInt32) { self = UInt(bitPattern) }
}
#endif


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

Re: [swift-evolution] [Pitch] BitPatternRepresentable

[Jens Persson via swift-evolution]

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 UInt16(bitPattern: self) }
init(bitPattern: UInt16) { self = Int16(bitPattern: bitPattern) }
}
extension Int32 : BitPatternRepresentable {
var bitPattern: UInt32 { return UInt32(bitPattern: self) }
init(bitPattern: UInt32) { self = Int32(bitPattern: bitPattern) }
}
extension Int64 : BitPatternRepresentable {
var bitPattern: UInt64 { return UInt64(bitPattern: self) }
init(bitPattern: UInt64) { self = Int64(bitPattern: bitPattern) }
}


On Tue, Jul 11, 2017 at 1:57 PM, Jens Persson  wrote:

> 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 can be converted to and from an associated BitPattern type.
> protocol BitPatternRepresentable {
> associatedtype BitPattern
> var bitPattern: BitPattern { get }
> init(bitPattern: BitPattern)
> }
>
> I think it's preferable to keep the conforming type's BitPatterns to the
> most basic (most "BitPattern-like" types) so eg
> UInt8, UInt16, UInt32, UInt64
> rather than
> Int8, Int16, Int32, Int64
> and, depending on platform
> UInt64, UInt32
> rather than
> Int or UInt.
>
> PS
>
> // Double and Float already fulfill the requirements of
> BitPatternRepresentable so:
>
> extension Double : BitPatternRepresentable {}
> extension Float : BitPatternRepresentable {}
>
> // And here is the rest of the types that I've used:
>
> extension UInt8 : BitPatternRepresentable {
> var bitPattern: UInt8 { return self }
> init(bitPattern: UInt8) { self = bitPattern }
> }
> extension UInt16 : BitPatternRepresentable {
> var bitPattern: UInt16 { return self }
> init(bitPattern: UInt16) { self = bitPattern }
> }
> extension UInt32 : BitPatternRepresentable {
> var bitPattern: UInt32 { return self }
> init(bitPattern: UInt32) { self = bitPattern }
> }
> extension UInt64 : BitPatternRepresentable {
> var bitPattern: UInt64 { return self }
> init(bitPattern: UInt64) { self = bitPattern }
> }
> #if arch(x86_64) || arch(arm64)
> extension Int : BitPatternRepresentable {
> var bitPattern: UInt64 { return UInt64(UInt.init(bitPattern:
> self)) }
> init(bitPattern: UInt64) { self = Int(Int64(bitPattern:
> bitPattern)) }
> }
> extension UInt : BitPatternRepresentable {
> var bitPattern: UInt64 { return UInt64(self) }
> init(bitPattern: UInt64) { self = UInt(bitPattern) }
> }
> #elseif arch(i386) || arch(arm)
> extension Int : BitPatternRepresentable {
> var bitPattern: UInt32 { return UInt32(UInt.init(bitPattern:
> self)) }
> init(bitPattern: UInt32) { self = Int(Int32(bitPattern:
> bitPattern)) }
> }
> extension UInt : BitPatternRepresentable {
> var bitPattern: UInt32 { return UInt32(self) }
> init(bitPattern: UInt32) { self = UInt(bitPattern) }
> }
> #endif
>
>
> /Jens
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jens Persson via swift-evolution]

Thanks for that clarification John McCall.
My code is using a lot of generic structs (in which memory layout is
important) though, an example would be:
struct Vector4 : Vector {
typealias Index = VectorIndex4
typealias Element = E
var e0, e1, e2, e3: Element
…
}
And I guess I'm out of luck trying to represent those as C structs?
So AFAICS it looks like it is currently impossible to write generic low
level code in Swift, unless I just keep doing what I've been doing (It does
currently work after all) knowing that it will probably break in some
future versions of Swift. But in that possible future version of Swift, I
could probably find a way to make it work again (using some possible
explicit tools for layout control present in that version of Swift).
Correct?
/Jens


On Sun, Jul 9, 2017 at 11:41 PM, John McCall  wrote:

>
> On Jul 9, 2017, 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]
> from their vertices: [Vertex] using the floatBuffer() method of the Vertex
> struct, which returns an Array with the stored properties of Vertex in
> correct order.
>
> While searching the internet about this I saw Joe Groff mentioning on
> Twitter that:
> "We plan to sort fields in padding order to minimize size, and may also
> automatically pack bools and enums in bitfields."
>
> So AFAICS my current image processing code is making the possibly invalid
> assumption that eg
> struct S {
> var a, b, c, d: Float
> }
> will have a memory layout of 4*4=16 bytes (stride and size == 16) and an
> alignment of 4, and most importantly that a, b, c, d will be in that order.
>
>
> This is currently true, but may not always be.  We want to reserve the
> right to re-order the fields even if it doesn't improve packing — for
> example, if two fields are frequently accessed together, field reordering
> could yield substantial locality benefits.  We've also discussed reordering
> fields to put them in a canonical order for resilience, since it's a little
> counter-intuitive that reordering the fields of a struct should be
> ABI-breaking.  (There are arguments against doing that as well, of course —
> for example, the programmer may have chosen the current order for their own
> locality optimizations.)
>
> It looks like I should be defining my structs (the ones for which memory
> layout is important) in C and import them.
>
>
> This should always work, yes.
>
> Although I would be surprised if a Swift-struct containing only same-sized
> fields (all of the same primitive type) would be reordered, and such
> changes to the language would probably include some per-struct way to
> express some sort of layout control (since being able to define structs to
> be used for low level data manipulation is important in a systems language).
>
>
> Exactly.  In the long term, Swift will have some explicit tools for layout
> control.
>
> John.
>
>
> /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 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: vImagePixelCount(table.size.e1),
>> width: vImagePixelCount(table.size.e0),
>> rowBytes: table.stride.e1
>> )
>> return withExtendedLifetime(table) { body(vib) }
>> }
>>
>> Here, Table is the raster image. Data.Coordinate == VectorIndex2
>> makes it a 2D table, and a Table's Data also has a type parameter
>> Data.Value which can be eg one of the "pixel"-struct I showed before.
>> This works without any problems (I've tested and used the some variant of
>> this type of code for years) but it would surely break if the memory layout
>> of simple structs changed.
>>
>> I can't see how this usage is much different from the one in the Metal
>> tutorial. It too uses pointers to point into a data created using the
>> (Swift) struct "Vertex", and the GPU hardware has its expectations on the
>> memory layout of that data, so the code would break if the memory layout of
>> the Vertex struct changed.
>>
>> /Jens
>>
>>
>> On Sun, Jul 9, 2017 at 6:35 PM, Jens Persson  wr

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

[Jens Persson via swift-evolution]

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]
from their vertices: [Vertex] using the floatBuffer() method of the Vertex
struct, which returns an Array with the stored properties of Vertex in
correct order.

While searching the internet about this I saw Joe Groff mentioning on
Twitter that:
"We plan to sort fields in padding order to minimize size, and may also
automatically pack bools and enums in bitfields."

So AFAICS my current image processing code is making the possibly invalid
assumption that eg
struct S {
var a, b, c, d: Float
}
will have a memory layout of 4*4=16 bytes (stride and size == 16) and an
alignment of 4, and most importantly that a, b, c, d will be in that order.

It looks like I should be defining my structs (the ones for which memory
layout is important) in C and import them.

Although I would be surprised if a Swift-struct containing only same-sized
fields (all of the same primitive type) would be reordered, and such
changes to the language would probably include some per-struct way to
express some sort of layout 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 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: vImagePixelCount(table.size.e1),
> width: vImagePixelCount(table.size.e0),
> rowBytes: table.stride.e1
> )
> return withExtendedLifetime(table) { body(vib) }
> }
>
> Here, Table is the raster image. Data.Coordinate == VectorIndex2
> makes it a 2D table, and a Table's Data also has a type parameter
> Data.Value which can be eg one of the "pixel"-struct I showed before.
> This works without any problems (I've tested and used the some variant of
> this type of code for years) but it would surely break if the memory layout
> of simple structs changed.
>
> I can't see how this usage is much different from the one in the Metal
> tutorial. It too uses pointers to point into a data created using the
> (Swift) struct "Vertex", and the GPU hardware has its expectations on the
> memory layout of that data, so the code would break if the memory layout of
> the Vertex struct changed.
>
> /Jens
>
>
> On Sun, Jul 9, 2017 at 6:35 PM, Jens Persson  wrote:
>
>> 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 surely depends on the fields of the Vertex struct (x, y, z, r, g,
>> b, a) being in the specified order (ie swapping the red channel with the x
>> coordinate would produce an unexpected result).
>>
>> And regarding the second example, pixel structs used for manipulating
>> raster image data. Manipulating raster image data presumably includes stuff
>> like displaying to screen, loading and saving raster images.
>> I currently use this way of doing this right now without any problems,
>> but if the order of the fields (eg a, r, g, b) should change in the future,
>> then my code would break (the colors of the images would at least not come
>> out as expected).
>>
>> /Jens
>>
>>
>>
>>
>>
>>
>> On Sun, Jul 9, 2017 at 5:53 PM, Chris Lattner 
>> wrote:
>>
>>>
>>> On Jul 9, 2017, at 12:23 AM, Jens Persson  wrote:
>>>
>>>
>>> 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 ABI stability for fragile structs lands, you
>>>> will be able to count on it, but until then something like this is probably
>>>> a bad idea.
>>>>
>>>> -Chris
>>>>
>>>
>>> Does this imply that you should never use Swift structs to eg interact
>&g

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

[Jens Persson via swift-evolution]

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: vImagePixelCount(table.size.e1),
width: vImagePixelCount(table.size.e0),
rowBytes: table.stride.e1
)
return withExtendedLifetime(table) { body(vib) }
}

Here, Table is the raster image. Data.Coordinate == VectorIndex2
makes it a 2D table, and a Table's Data also has a type parameter
Data.Value which can be eg one of the "pixel"-struct I showed before.
This works without any problems (I've tested and used the some variant of
this type of code for years) but it would surely break if the memory layout
of simple structs changed.

I can't see how this usage is much different from the one in the Metal
tutorial. It too uses pointers to point into a data created using the
(Swift) struct "Vertex", and the GPU hardware has its expectations on the
memory layout of that data, so the code would break if the memory layout of
the Vertex struct changed.

/Jens


On Sun, Jul 9, 2017 at 6:35 PM, Jens Persson  wrote:

> 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
> surely depends on the fields of the Vertex struct (x, y, z, r, g, b, a)
> being in the specified order (ie swapping the red channel with the x
> coordinate would produce an unexpected result).
>
> And regarding the second example, pixel structs used for manipulating
> raster image data. Manipulating raster image data presumably includes stuff
> like displaying to screen, loading and saving raster images.
> I currently use this way of doing this right now without any problems, but
> if the order of the fields (eg a, r, g, b) should change in the future,
> then my code would break (the colors of the images would at least not come
> out as expected).
>
> /Jens
>
>
>
>
>
>
> On Sun, Jul 9, 2017 at 5:53 PM, Chris Lattner  wrote:
>
>>
>> On Jul 9, 2017, at 12:23 AM, Jens Persson  wrote:
>>
>>
>> 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 ABI stability for fragile structs lands, you
>>> will be able to count on it, but until then something like this is probably
>>> a bad idea.
>>>
>>> -Chris
>>>
>>
>> Does this imply that you should never use Swift structs to eg interact
>> with Metal?
>>
>>
>> No.
>>
>> This seems to be a very common practice. Here is a typical example (from
>> a Metal tutorial at raywenderlich.com):
>>
>> struct Vertex {
>>   var x,y,z: Float // position data
>>   var r,g,b,a: Float   // color data
>>
>>   func floatBuffer() -> [Float] {
>> return [x,y,z,r,g,b,a]
>>   }
>> }
>>
>>
>> This doesn’t appear to expose the layout of the struct.
>>
>> Also, does it imply that we cannot use structs (of only primitive types)
>> like:
>>
>> struct RgbaFloatsLinearGamma {
>> var r, g, b, a: Float
>> …
>> }
>> struct BgraBytesSrgbGamma {
>> var b, g, r, a: UInt8
>> }
>>
>> for manipulating raster image data?
>>
>>
>> I don’t see why that would be a problem.
>>
>> I vaguely remember a swift evo discussion where it was concluded that
>> such usage was considered OK provided the stored properties of the structs
>> was only primitive types, but I can't find it now.
>>
>> Perhaps it could be considered OK at least when the intended platforms
>> are known to be only iOS devices?
>>
>>
>> I think you’re misunderstanding what I’m saying.  It isn’t correct to
>> take (e.g.) an unsafepointer to the beginning of a struct, and serialize
>> that out to disk, and expect that the fields are emitted in some order with
>> some specific padding between them.  None of the uses above try to do this.
>>
>> -Chris
>>
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jens Persson via swift-evolution]

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
surely depends on the fields of the Vertex struct (x, y, z, r, g, b, a)
being in the specified order (ie swapping the red channel with the x
coordinate would produce an unexpected result).

And regarding the second example, pixel structs used for manipulating
raster image data. Manipulating raster image data presumably includes stuff
like displaying to screen, loading and saving raster images.
I currently use this way of doing this right now without any problems, but
if the order of the fields (eg a, r, g, b) should change in the future,
then my code would break (the colors of the images would at least not come
out as expected).

/Jens






On Sun, Jul 9, 2017 at 5:53 PM, Chris Lattner  wrote:

>
> On Jul 9, 2017, at 12:23 AM, Jens Persson  wrote:
>
>
> 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 ABI stability for fragile structs lands, you
>> will be able to count on it, but until then something like this is probably
>> a bad idea.
>>
>> -Chris
>>
>
> Does this imply that you should never use Swift structs to eg interact
> with Metal?
>
>
> No.
>
> This seems to be a very common practice. Here is a typical example (from a
> Metal tutorial at raywenderlich.com):
>
> struct Vertex {
>   var x,y,z: Float // position data
>   var r,g,b,a: Float   // color data
>
>   func floatBuffer() -> [Float] {
> return [x,y,z,r,g,b,a]
>   }
> }
>
>
> This doesn’t appear to expose the layout of the struct.
>
> Also, does it imply that we cannot use structs (of only primitive types)
> like:
>
> struct RgbaFloatsLinearGamma {
> var r, g, b, a: Float
> …
> }
> struct BgraBytesSrgbGamma {
> var b, g, r, a: UInt8
> }
>
> for manipulating raster image data?
>
>
> I don’t see why that would be a problem.
>
> I vaguely remember a swift evo discussion where it was concluded that such
> usage was considered OK provided the stored properties of the structs was
> only primitive types, but I can't find it now.
>
> Perhaps it could be considered OK at least when the intended platforms are
> known to be only iOS devices?
>
>
> I think you’re misunderstanding what I’m saying.  It isn’t correct to take
> (e.g.) an unsafepointer to the beginning of a struct, and serialize that
> out to disk, and expect that the fields are emitted in some order with some
> specific padding between them.  None of the uses above try to do this.
>
> -Chris
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jens Persson via swift-evolution]

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 ABI stability for fragile structs lands, you
> will be able to count on it, but until then something like this is probably
> a bad idea.
>
> -Chris
>

Does this imply that you should never use Swift structs to eg interact with
Metal?

This seems to be a very common practice. Here is a typical example (from a
Metal tutorial at raywenderlich.com):

struct Vertex {
  var x,y,z: Float // position data
  var r,g,b,a: Float   // color data

  func floatBuffer() -> [Float] {
return [x,y,z,r,g,b,a]
  }
}

(
https://www.raywenderlich.com/146416/metal-tutorial-swift-3-part-2-moving-3d
 )

Also, does it imply that we cannot use structs (of only primitive types)
like:

struct RgbaFloatsLinearGamma {
var r, g, b, a: Float
…
}
struct BgraBytesSrgbGamma {
var b, g, r, a: UInt8
}

for manipulating raster image data?

I vaguely remember a swift evo discussion where it was concluded that such
usage was considered OK provided the stored properties of the structs was
only primitive types, but I can't find it now.

Perhaps it could be considered OK at least when the intended platforms are
known to be only iOS devices?

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

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

[Jens Persson via swift-evolution]

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 used somewhere in the std lib?

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

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

[Jens Persson via swift-evolution]

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 naturally it
> cannot be done implicitly either.
>
> On Tue, Jun 13, 2017 at 12:29 Jens Persson  wrote:
>
>> 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 allowed to call swap()?
>> Or is there a third alternative?
>> /Jens
>>
>> On Tue, Jun 13, 2017 at 7:15 PM, John McCall via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> On Jun 13, 2017, at 4:41 AM, Xiaodi Wu  wrote:
>>>
>>> On Tue, Jun 13, 2017 at 3:06 AM, John McCall  wrote:
>>>
 On Jun 13, 2017, at 3:30 AM, Jérémie Girault 
 wrote:

 Exactly,
 The reflexion behind it is:

 - Let's understand that 0110 and other tuple SE are important for the
 compiler, we do not want them to rollback
 - However we have number of regressions for generics / functional
 programmers
 - Let’s solve this step by step like a typical problem

 - Step 0 is adressing this Void tuple of size zero :
 - Zero is in many problems of CS an edge case, so let’s handle this
 case first
 - The compiler knows what Void is, and its only value (or non-value)
 - It was handled historically by the compiler because of implicit side
 effects
 - Let’s handle it explicitely with rules in current context
 - one effect of the proposal is source compatibility
 - but the goal is to build atop and strengthen 0110, 0066 and other
 tuple-related SE


 There are four difficulties I see with this proposal.

 The first is that it is a first step that quite clearly does not lead
 to anything.  It resolves a difficulty with exactly one case of function
 composition, but we would need completely different solutions to handle any
 of the other compositional regressions of SE-0110.

 The second is that it's a huge source of complexity for the type
 system.  The type checker would not be able to do even rudimentary type
 matching, e.g. when checking a call, without having first resolved all of
 the argument and parameter types to prove that they are not Void.  This
 would probably render it impossible to type-check many programs without
 some ad-hoc rule of inferring that certain types are not Void.  It would
 certainly make type-checking vastly more expensive.

 The third is that it is not possible to prevent values of Void from
 existing, because (unlike Never, which cannot be constructed) they are
 always created by returning from a Void-returning function, and a generic
 function can do anything it likes with that value — turn it into an Any,
 store it in an Array, whatever.  The proposal seems to only consider using
 the value as a parameter.

>>>
>>> Hang on, though. If Jérémie is interested only in addressing the issue
>>> of Void as a parameter and his idea can be adequately carried out by
>>> inferring a default value of Void for every parameter of type Void, this
>>> should be a fairly self-contained change, should it not? And would the
>>> impact on the cost of type checking really be vastly greater in that case?
>>>
>>>
>>> If the proposal was phrased in terms of defaults, e.g. "trailing
>>> parameters do not require a matching argument if they have Void type", then
>>> yes, that would be implementable because it still admits a "local"
>>> reduction on call constraints, one which does not need to immediately
>>> reason about the actual types of arguments.  It is not clear that this rule
>>> allows function compositions of the sort that Jérémie is looking for,
>>> though.
>>>
>>> Anyway, that is not the proposal; the proposal is that parameters — in
>>> any position — are simply removed from the parameter sequence if they have
>>> Void type.  In order to allow composition (i.e. f(g(x)), where g: X ->
>>> Void), you then need a matching rule that arguments are dropped from the
>>> argument sequence (for purposes of type-checking) if they have Void type.
>>> Either of these rules is sufficient to turn the reduction of function-type
>>> matches into an extremely messy combinatoric matching problem where e.g.
>>> (τ0, Int) can be passed to a function taking (Int, τ1) if we can decide
>>> that τ0 == τ1 == Void.
>>>
>>> This idea is now rather intriguing to me because it extends beyond just
>>> addressing one symptom of SE-0110. Swift allows us to omit the spelling out
>>> of return types that are Void, it allows warning-free discarding of return
>>> values that are Void, etc. T

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

[Jens Persson via swift-evolution]

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 allowed to call swap()?
Or is there a third alternative?
/Jens


On Tue, Jun 13, 2017 at 7:15 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jun 13, 2017, at 4:41 AM, Xiaodi Wu  wrote:
>
> On Tue, Jun 13, 2017 at 3:06 AM, John McCall  wrote:
>
>> On Jun 13, 2017, at 3:30 AM, Jérémie Girault 
>> wrote:
>>
>> Exactly,
>> The reflexion behind it is:
>>
>> - Let's understand that 0110 and other tuple SE are important for the
>> compiler, we do not want them to rollback
>> - However we have number of regressions for generics / functional
>> programmers
>> - Let’s solve this step by step like a typical problem
>>
>> - Step 0 is adressing this Void tuple of size zero :
>> - Zero is in many problems of CS an edge case, so let’s handle this case
>> first
>> - The compiler knows what Void is, and its only value (or non-value)
>> - It was handled historically by the compiler because of implicit side
>> effects
>> - Let’s handle it explicitely with rules in current context
>> - one effect of the proposal is source compatibility
>> - but the goal is to build atop and strengthen 0110, 0066 and other
>> tuple-related SE
>>
>>
>> There are four difficulties I see with this proposal.
>>
>> The first is that it is a first step that quite clearly does not lead to
>> anything.  It resolves a difficulty with exactly one case of function
>> composition, but we would need completely different solutions to handle any
>> of the other compositional regressions of SE-0110.
>>
>> The second is that it's a huge source of complexity for the type system.
>> The type checker would not be able to do even rudimentary type matching,
>> e.g. when checking a call, without having first resolved all of the
>> argument and parameter types to prove that they are not Void.  This would
>> probably render it impossible to type-check many programs without some
>> ad-hoc rule of inferring that certain types are not Void.  It would
>> certainly make type-checking vastly more expensive.
>>
>> The third is that it is not possible to prevent values of Void from
>> existing, because (unlike Never, which cannot be constructed) they are
>> always created by returning from a Void-returning function, and a generic
>> function can do anything it likes with that value — turn it into an Any,
>> store it in an Array, whatever.  The proposal seems to only consider using
>> the value as a parameter.
>>
>
> Hang on, though. If Jérémie is interested only in addressing the issue of
> Void as a parameter and his idea can be adequately carried out by inferring
> a default value of Void for every parameter of type Void, this should be a
> fairly self-contained change, should it not? And would the impact on the
> cost of type checking really be vastly greater in that case?
>
>
> If the proposal was phrased in terms of defaults, e.g. "trailing
> parameters do not require a matching argument if they have Void type", then
> yes, that would be implementable because it still admits a "local"
> reduction on call constraints, one which does not need to immediately
> reason about the actual types of arguments.  It is not clear that this rule
> allows function compositions of the sort that Jérémie is looking for,
> though.
>
> Anyway, that is not the proposal; the proposal is that parameters — in any
> position — are simply removed from the parameter sequence if they have Void
> type.  In order to allow composition (i.e. f(g(x)), where g: X -> Void),
> you then need a matching rule that arguments are dropped from the argument
> sequence (for purposes of type-checking) if they have Void type.  Either of
> these rules is sufficient to turn the reduction of function-type matches
> into an extremely messy combinatoric matching problem where e.g. (τ0, Int)
> can be passed to a function taking (Int, τ1) if we can decide that τ0 == τ1
> == Void.
>
> This idea is now rather intriguing to me because it extends beyond just
> addressing one symptom of SE-0110. Swift allows us to omit the spelling out
> of return types that are Void, it allows warning-free discarding of return
> values that are Void, etc. This could add a nice consistency and
> rationalize some of the weirdness of passing a value that is stipulated by
> the parameter type.
>
> Finally, it would allow a lot of inadvertent errors with the use of
>> generic functions, because any argument of unconstrained type could be
>> accidentally specialized with Void.  For example, if you forgot to pass an
>> argument to this function, it would simply infer T=Void:
>>   func append(value: T)
>> It seems more likely that this would lead to unexpected, frustrating bugs
>> than that this would actually be desired by the 

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

[Jens Persson via swift-evolution]

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  wrote:

> On 12.06.2017 23:17, Jens Persson via swift-evolution wrote:
>
>> 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
>> (latest dev snapshot) Swift 4, so this is the behavior of both Swift 3(.2)
>> and 4:
>> func foo() -> Void {}
>> func foo(_: Void) -> Void {} // This is OK
>> func bar(fn: () -> Void) {}
>> func bar(fn: (_: Void) -> Void) {} // ERR: Invalid redecl.
>>
>> I think the least surprising behavior here would be no error, rather than
>> two.
>> The current behavior with one error is very surprising.
>>
>
> As I understand, currently in Swift 4 there are a number of bugs related
> to function types, so I believe it is incorrect to make conclusions based
> on current behavior of Swift 4 code. I've asked John McCall in this thread
> about *planned* behavior of some Swift 4 release code related to function
> types, let's see what will be the reply.
>
> (I'd suggest to create a bug on bugs.swift.org for this particular issue
> - probably this will help to improve Swift 4 compiler)
>
>
>>
>> On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault <
>> jeremie.gira...@gmail.com
>> <mailto:jeremie.gira...@gmail.com>> wrote:
>>
>> Exactly, that means that your implementation of the tuple
>> splatting operator
>> is out of the type system.
>> Can you expose it’s signature ?
>>
>> If you want the operator to be “compiler-magic” it’s possible.
>>
>> Yes, it requires compiler support.
>>
>> This proposal is an alternate solution.
>>
>> My point is that updating Void according to this proposal would
>>   - preserve the type system in a better way
>>   - have better source compatibility (in time for swift 4
>> release, were we
>> probably won’t see tuple splatting)
>>   - also keep the elegant original syntax of swift instead of
>> stacking
>> parenthesis
>>
>> The impact for code writers would be minimized on time for swift
>> 4 release
>>
>> As for return values: this proposition does not intend to change
>> the how
>> return value of Void functions works.
>>
>> —
>> very short reply expected - vsre.info <http://vsre.info>
>> Jérémie Girault
>>
>> On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi...@gmail.com
>> <mailto:xiaodi...@gmail.com>) wrote:
>>
>> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault<
>>> jeremie.gira...@gmail.com
>>> <mailto:jeremie.gira...@gmail.com>>wrote:
>>>
>>> @xiaodi
>>> I disagree on many points, for example what is the type of x
>>> when we
>>> type `let x = *Void` ?
>>>
>>>
>>> That would not be a legal statement. Exploding a tuple is an
>>> operation that
>>> only makes sense inside an argument list. Likewise `let x =
>>> &Void` will not
>>> compile.
>>>
>>> This is the essence of the problem and this proposition
>>> wants to solve
>>> this.
>>>
>>> The regression is due to both reason combined : typealias
>>> Void = () AND
>>> SE-0110
>>>
>>> My proposition is to change the meaning of Void from () to
>>> “something
>>> else” that is type-compatible with SE-0110 (and splatting in
>>> the future).
>>>
>>>
>>> I'm not sure I understand your motivation. Void is just a
>>> typealias. If
>>> tomorrow Void meant something else, all functions must still
>>> return (), and
>>> there is still no implicit tuple splatting.
>>>
>>
>>
>>
>>> 

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

[Jens Persson via swift-evolution]

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
(latest dev snapshot) Swift 4, so this is the behavior of both Swift 3(.2)
and 4:
func foo() -> Void {}
func foo(_: Void) -> Void {} // This is OK
func bar(fn: () -> Void) {}
func bar(fn: (_: Void) -> Void) {} // ERR: Invalid redecl.

I think the least surprising behavior here would be no error, rather than
two.
The current behavior with one error is very surprising.


On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault <
> jeremie.gira...@gmail.com> wrote:
>
>> Exactly, that means that your implementation of the tuple splatting
>> operator is out of the type system.
>> Can you expose it’s signature ?
>>
>> If you want the operator to be “compiler-magic” it’s possible.
>>
>
> Yes, it requires compiler support.
>
>
>> This proposal is an alternate solution.
>>
>> My point is that updating Void according to this proposal would
>>  - preserve the type system in a better way
>>  - have better source compatibility (in time for swift 4 release, were we
>> probably won’t see tuple splatting)
>>  - also keep the elegant original syntax of swift instead of stacking
>> parenthesis
>>
>> The impact for code writers would be minimized on time for swift 4 release
>>
>> As for return values: this proposition does not intend to change the how
>> return value of Void functions works.
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>
>> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault > .com> wrote:
>>
>>> @xiaodi
>>> I disagree on many points, for example what is the type of x when we
>>> type `let x = *Void` ?
>>>
>>
>> That would not be a legal statement. Exploding a tuple is an operation
>> that only makes sense inside an argument list. Likewise `let x = &Void`
>> will not compile.
>>
>>
>>> This is the essence of the problem and this proposition wants to solve
>>> this.
>>>
>>> The regression is due to both reason combined : typealias Void = () AND
>>> SE-0110
>>>
>>> My proposition is to change the meaning of Void from () to “something
>>> else” that is type-compatible with SE-0110 (and splatting in the future).
>>>
>>
>> I'm not sure I understand your motivation. Void is just a typealias. If
>> tomorrow Void meant something else, all functions must still return (), and
>> there is still no implicit tuple splatting.
>>
>>
>>
>>
>>
>>> If you want an example of the changes needed to migrate to swift4, just
>>> look at the 42 files of handling parenthesis PR of RxSwift needed for
>>> swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files
>>>
>>
>> Indeed, that's the result of SE-0110; these parentheses are needed
>> because there is no implicit tuple splatting. They would be required even
>> if `Void` did not exist in the language at all.
>>
>>
>>>
>>> —
>>> very short reply expected - vsre.info
>>> Jérémie Girault
>>>
>>> On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>>
>>> On Mon, Jun 12, 2017 at 2:05 PM, David Hart  wrote:
>>>

 On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:

 Unfortunately, I think this proposal appears to be mistaken as to this
 key premise: Void was never (IIUC) meant to model the absence of arguments;
 it is a type with one possible value.

 If I recall, a number of conversations have been raised about Void
 being a typealias of (), and the definitive response has been that this
 falls into the ship-has-sailed category of out-of-scope changes.

 More generally, the recent spate of complaints about regressions to a
 particular coding style have to do with loss of implicit tuple splatting,
 the cure for which is a proper implementation of tuple splatting, not
 poking holes into settled parts of the type system.


 But you can’t deny that SE-0110 has also caused regressions in the use
 of Void as generic argument because Void is modelled as the empty tuple.

>>>
>>> I'm not sure I understand this statement. Void is a synonym for the
>>> empty tuple, and that hasn't ever changed, so it can't be the root cause of
>>> any regressions.
>>>
>>>
 And tuple splatting will not fix those regressions.

>>>
>>> How come? If `*` is the splat operator, then it would be legal to call a
>>> function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple
>>> splatting returns in fully implemented form, then it would be legal to call
>>> it once again with `foo(Void)`.
>>>
>>> And contrary to what some people might think, this is not an
 “edge-cas

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

[Jens Persson via swift-evolution]

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 foo(_: Void) {}
>> func bar() {}
>> // All these compile in Swift 3:
>> foo()
>> foo(())
>> bar()
>> bar(())
>> // But only these two compile in Swift 4:
>> foo(())
>> bar()
>>
>
> So, `foo` takes one argument of type `()` but `bar` takes zero arguments.
> The expectation that you can call a function with a single tuple of some
> arity instead of the declared number of arguments is fulfilled by implicit
> tuple splatting, which is intentionally removed. This has nothing to do
> with what `Void` means; the single argument could be `Int` or `String` or
> `Data`.
>
>
> On Mon, Jun 12, 2017 at 9:44 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault <
>>> jeremie.gira...@gmail.com> wrote:
>>>
 @xiaodi
 I disagree on many points, for example what is the type of x when we
 type `let x = *Void` ?

>>>
>>> That would not be a legal statement. Exploding a tuple is an operation
>>> that only makes sense inside an argument list. Likewise `let x = &Void`
>>> will not compile.
>>>
>>>
 This is the essence of the problem and this proposition wants to solve
 this.

 The regression is due to both reason combined : typealias Void = () AND
 SE-0110

 My proposition is to change the meaning of Void from () to “something
 else” that is type-compatible with SE-0110 (and splatting in the future).

>>>
>>> I'm not sure I understand your motivation. Void is just a typealias. If
>>> tomorrow Void meant something else, all functions must still return (), and
>>> there is still no implicit tuple splatting.
>>>
>>>
 If you want an example of the changes needed to migrate to swift4, just
 look at the 42 files of handling parenthesis PR of RxSwift needed for
 swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files

>>>
>>> Indeed, that's the result of SE-0110; these parentheses are needed
>>> because there is no implicit tuple splatting. They would be required even
>>> if `Void` did not exist in the language at all.
>>>
>>>

 —
 very short reply expected - vsre.info
 Jérémie Girault

 On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:

 On Mon, Jun 12, 2017 at 2:05 PM, David Hart  wrote:

>
> On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Unfortunately, I think this proposal appears to be mistaken as to this
> key premise: Void was never (IIUC) meant to model the absence of 
> arguments;
> it is a type with one possible value.
>
> If I recall, a number of conversations have been raised about Void
> being a typealias of (), and the definitive response has been that this
> falls into the ship-has-sailed category of out-of-scope changes.
>
> More generally, the recent spate of complaints about regressions to a
> particular coding style have to do with loss of implicit tuple splatting,
> the cure for which is a proper implementation of tuple splatting, not
> poking holes into settled parts of the type system.
>
>
> But you can’t deny that SE-0110 has also caused regressions in the use
> of Void as generic argument because Void is modelled as the empty tuple.
>

 I'm not sure I understand this statement. Void is a synonym for the
 empty tuple, and that hasn't ever changed, so it can't be the root cause of
 any regressions.


> And tuple splatting will not fix those regressions.
>

 How come? If `*` is the splat operator, then it would be legal to call
 a function `foo` that takes no arguments with `foo(*Void)`; if implicit
 tuple splatting returns in fully implemented form, then it would be legal
 to call it once again with `foo(Void)`.

 And contrary to what some people might think, this is not an
> “edge-case”. Most useful monads modelled with generics have good reasons 
> to
> use Void:
>
> *The Result monad:* Result represents the result of an
> operation with no return value
> *The Promise monad:* Promise represents the result of an
> asynchronous operation with no return value
> *The Observable monad (in functional reactive programming):*
> Observable represents a stream of events with no values
>
> I use all three monads in my code and I’ve had to modify a lot of code
> when migrating to Swift 4 beta1 because of Void.
>

 Can you give examples of the modifications needed during migration?
 From here, I can only see that the reason any code needs modification is
 the complete removal of implicit tuple splatt

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

[Jens Persson via swift-evolution]

Just adding this here for reference:
func foo(_: Void) {}
func bar() {}
// All these compile in Swift 3:
foo()
foo(())
bar()
bar(())
// But only these two compile in Swift 4:
foo(())
bar()


On Mon, Jun 12, 2017 at 9:44 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault <
> jeremie.gira...@gmail.com> wrote:
>
>> @xiaodi
>> I disagree on many points, for example what is the type of x when we type
>> `let x = *Void` ?
>>
>
> That would not be a legal statement. Exploding a tuple is an operation
> that only makes sense inside an argument list. Likewise `let x = &Void`
> will not compile.
>
>
>> This is the essence of the problem and this proposition wants to solve
>> this.
>>
>> The regression is due to both reason combined : typealias Void = () AND
>> SE-0110
>>
>> My proposition is to change the meaning of Void from () to “something
>> else” that is type-compatible with SE-0110 (and splatting in the future).
>>
>
> I'm not sure I understand your motivation. Void is just a typealias. If
> tomorrow Void meant something else, all functions must still return (), and
> there is still no implicit tuple splatting.
>
>
>> If you want an example of the changes needed to migrate to swift4, just
>> look at the 42 files of handling parenthesis PR of RxSwift needed for
>> swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files
>>
>
> Indeed, that's the result of SE-0110; these parentheses are needed because
> there is no implicit tuple splatting. They would be required even if `Void`
> did not exist in the language at all.
>
>
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>>
>> On Mon, Jun 12, 2017 at 2:05 PM, David Hart  wrote:
>>
>>>
>>> On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Unfortunately, I think this proposal appears to be mistaken as to this
>>> key premise: Void was never (IIUC) meant to model the absence of arguments;
>>> it is a type with one possible value.
>>>
>>> If I recall, a number of conversations have been raised about Void being
>>> a typealias of (), and the definitive response has been that this falls
>>> into the ship-has-sailed category of out-of-scope changes.
>>>
>>> More generally, the recent spate of complaints about regressions to a
>>> particular coding style have to do with loss of implicit tuple splatting,
>>> the cure for which is a proper implementation of tuple splatting, not
>>> poking holes into settled parts of the type system.
>>>
>>>
>>> But you can’t deny that SE-0110 has also caused regressions in the use
>>> of Void as generic argument because Void is modelled as the empty tuple.
>>>
>>
>> I'm not sure I understand this statement. Void is a synonym for the empty
>> tuple, and that hasn't ever changed, so it can't be the root cause of any
>> regressions.
>>
>>
>>> And tuple splatting will not fix those regressions.
>>>
>>
>> How come? If `*` is the splat operator, then it would be legal to call a
>> function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple
>> splatting returns in fully implemented form, then it would be legal to call
>> it once again with `foo(Void)`.
>>
>> And contrary to what some people might think, this is not an “edge-case”.
>>> Most useful monads modelled with generics have good reasons to use Void:
>>>
>>> *The Result monad:* Result represents the result of an
>>> operation with no return value
>>> *The Promise monad:* Promise represents the result of an
>>> asynchronous operation with no return value
>>> *The Observable monad (in functional reactive programming):*
>>> Observable represents a stream of events with no values
>>>
>>> I use all three monads in my code and I’ve had to modify a lot of code
>>> when migrating to Swift 4 beta1 because of Void.
>>>
>>
>> Can you give examples of the modifications needed during migration? From
>> here, I can only see that the reason any code needs modification is the
>> complete removal of implicit tuple splatting. Nothing has changed about
>> Void being a synonym for the empty tuple; even if you rename Void,
>> functions will still return () by some other name, and unless there is
>> tuple splatting in some form, the migration you performed is inevitable.
>>
>> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>

 On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
 swift-evolution@swift.org> wrote:

 Hi here,

 As I tested swift4 in xcode9b1 I noticed a lot of regressions about
 tuples usage.

 After documenting myself about the changes which happened, I thought
 that they could be improved. Instead of fighting these propositions (which
 make sense), I wanted create a few proposal which would improve these
 recent changes with a few sim

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

[Jens Persson via swift-evolution]

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 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 system?
>
>
> That's correct.  There's a lot of special structure to function calls —
> labels, overloading, default arguments, variadics, inout arguments,
> (eventually) borrowed arguments — that we do not want to introduce into the
> first-class tuple system, or at least not in the exact same way.  In some
> cases, like overloading or defaulted and inout arguments, it cannot be done
> without a major and unwanted model shift.  In other cases, like variadics,
> it could theoretically be done but would complicate the type system in ways
> we are trying to avoid.
>
> Regardless, the existence of any call-specific structure at all implies
> that generic value forwarding cannot always be sufficient to do generic
> argument forwarding.  Maybe that's an argument for not having any
> call-specific structure, but we do have that and it's not going away.
>
> John.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jens Persson via swift-evolution]

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 system?

My main problem/missing feature with function types in Swift 4 is not being
able to express a generic function type as A -> B, instead I would have to
do this:
(A) -> B
(A, B) -> C
(A, B, C) -> D
...
...
Ie it is impossible to fully express something that I normally see as just
A -> B.

Another example could be describing any two function types that are
composable:
A -> B and B -> C

This also becomes impossible using Swift 4 function types:
(A) -> B and (B) -> C
(A, B) -> C and (C) -> D
(A) -> (B, C) and (B, C) -> D
...
...
... etc, etc, ...

One solution that is already possible is of course to only use functions
with one (tuple) argument in these and similar scenarios. But that's still
a bit awkward.

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

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

[Jens Persson via swift-evolution]

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 functions must only
> take a single tuple rather than multiple arguments could affect the runtime
> representation of function types. But even then, there are approaches to
> mitigate this, so such a proposal would likely present an ABI migration
> strategy.
>
>
I think I understand (and understood), in very basic terms, the difference
between source stability and binary stability, and I was thinking something
like this:

What if there is a chance that the "uniform tuple concept" could be
redesigned and reimplemented after all, handling inout, variadic, etc in
some way, allowing named single element tuples, allowing A -> B to
represent (possibly only "pure") functions with _any_number_ of args, and
not just one, as in Swift 4, and so on.

I'm still not entirely sure if this is ABI-affecting or not. But anyway,
thank you for your calming words!

(I will try to not worry that (almost) everything parentheses-related in
Swift will forever be stuck in a local optimum, because its current state
and the history that lead to it is so confusing that it will stop all
attempts at a substantially better solution and only allow minor
changes/polishing.)

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

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

[Jens Persson via swift-evolution]

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
foo(fnB) // Compiles in both Swift 3 and Swift 4
foo(fnC) // Compiles in Swift 3, error in Swift 4

From what I read in your proposal, I assume that you want foo(fnA) to
compile in both.
But if so, don't you think foo(fnC) should also compile in both?

/Jens


On Mon, Jun 12, 2017 at 10:48 AM, Jérémie Girault via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi here,
>
> As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples
> usage.
>
> After documenting myself about the changes which happened, I thought that
> they could be improved. Instead of fighting these propositions (which make
> sense), I wanted create a few proposal which would improve these recent
> changes with a few simple rules.
>
> My propositions are based on the recent decisions and in the continuation
> of SE-0110. The first one is about Void.
> Void is historically defined as the type of the empty tuple. The reason of
> this is that arguments were initially considered as tuple. If this is no
> more the case, then it’s no more a reason to keep Void as an empty tuple.
>
> I think that by having a few rules around tuples of cardinality 0 and 1
> and also arguments list, we could greatly improve source compatibility and
> keep a lot of what makes swift great when using functional style and
> generics.
>
> I drafted a proposal that would allow more source compatibility and type
> consistency and would enjoy discussing it with you, in order to improve it
> :
>
> https://github.com/jeremiegirault/swift-evolution/blob/master/
> proposals/-flatten-void.md
>
> Let me know what you think about it,
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> ___
> 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] History and future of Swift's parentheses

[Jens Persson via swift-evolution]

The topic of this thread:
It is simply the history and future of parentheses in Swift. My initial
post is just a starting point, it could have been something else. But I'm
interested to hear what people have to say about the history and future of
Swift's parentheses.

What is messy:
As I said, many things parentheses-related in Swift are (at least
currently) messy: tuples, func calling, -definitions, -signatures, -types,
discussions about them, etc.

It's hard to discuss (and probably design) a system in which parentheses
are used for so many different but intertweaved concepts (is there a
complete list of all the uses for parentheses in Swift?).

There are many concrete examples of this  parentheses-related "mess",
namely bugs and/or inconsistencies. See for example the four bugs I was
just recently asked to file in this thread:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170605/037049.html

Similar inconsistencies and bugs have been in Swift since the first beta.

Why are they still there? Why does it take so long to get rid of them?

Again, I think part of the problem is that the multipurpose parentheses
confuses people and also makes it necessary to add special rules to handle
clashes in the syntax which would perhaps not have been there if
parentheses hadn't been used for so many different things.

Don't know if that clarified anything or if I'm just repeating myself.

I'm not seeking to discuss any particular kinds of cleaning up, just
interested to hear anything people think about related to parentheses in
Swift (tuples, paramter lists, argument lists, pattern matching, ...).

/Jens


On Sat, Jun 10, 2017 at 2:00 AM, Xiaodi Wu  wrote:

> I'm confused as to the topic of this thread:
>
> On the one hand, you're starting off with a statement about parentheses
> being used for multiple different things, suggesting that what you want to
> discuss is related to spelling using parentheses.
>
> OTOH, the exercises that you put forward show that you're concerned about
> the loss of implicit tuple splatting, a well-acknowledged regression, for
> which the way forward is to introduce explicit tuple splatting at some
> point in the future (at least, according to SE-0029, that's the intended
> direction for Swift).
>
> What, in the end, are you claiming to be "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
>> that it was a special rule that was invented to resolve a problem/situation
>> with no clear best solution. Probably most people agree now that the
>> current simpler and more uniform rule set for parameter labels are
>> obviously better. It was possible to escape the ugly special case of the
>> first parameter, after all.
>>
>> Similarly, I wonder if the parentheses-related mess actually can be
>> simpler and more uniform, after all. I remember a lot of discussions in
>> which people argued that Swift couldn't and/or shouldn't get rid of the
>> special first parameter label rules.
>>
>> I'm not a compiler hacker and I have no idea exactly what aspects of the
>> language is easy/hard/impossible to change once Swift is binary stable.
>>
>> My concrete concerns are that the messy parentheses-related parts of the
>> language will continue to be messy for ever.
>> I have no idea if there is any actual reason to worry about that, but ABI
>> stability was originally intended for Swift 3, and then it was postponed
>> because some stuff needed to be done before ABI stability. Now I'm just
>> worried that solving the parentheses situation is something that needs to
>> be done before ABI stability. Please correct/enlighten me!
>>
>> /Jens
>>
>>
>>
>> On Sat, Jun 10, 2017 at 12:50 AM, Michael Ilseman 
>> wrote:
>>
>>>
>>>
>>> On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> 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 have to special-case it for
>>> every combination of parameter counts of f and g that it should be able to
>>> handle.
>>>
>>> The following program demonstrates how it can be done in 

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

[Jens Persson via swift-evolution]

The analogy of the special first parameter label was relevant (for me) in
that it was a special rule that was invented to resolve a problem/situation
with no clear best solution. Probably most people agree now that the
current simpler and more uniform rule set for parameter labels are
obviously better. It was possible to escape the ugly special case of the
first parameter, after all.

Similarly, I wonder if the parentheses-related mess actually can be simpler
and more uniform, after all. I remember a lot of discussions in which
people argued that Swift couldn't and/or shouldn't get rid of the special
first parameter label rules.

I'm not a compiler hacker and I have no idea exactly what aspects of the
language is easy/hard/impossible to change once Swift is binary stable.

My concrete concerns are that the messy parentheses-related parts of the
language will continue to be messy for ever.
I have no idea if there is any actual reason to worry about that, but ABI
stability was originally intended for Swift 3, and then it was postponed
because some stuff needed to be done before ABI stability. Now I'm just
worried that solving the parentheses situation is something that needs to
be done before ABI stability. Please correct/enlighten me!

/Jens



On Sat, Jun 10, 2017 at 12:50 AM, Michael Ilseman 
wrote:

>
>
> On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 have to special-case it for
> every combination of parameter counts of f and g that it should be able to
> handle.
>
> The following program demonstrates how it can be done in Swift 3.1 and 3.2:
>
> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) ->
> (T) -> V {
> return { x in g(f(x)) }
> }
> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
> func square(_ a: Int) -> Int { return a * a }
> let squaredSum = compose(square, sum)
> let result = squaredSum((3, 4)) // A bit unexepected with a tuple here but
> ok ...
> print(result) // 49
> // Well, it worked, not flawlessly but we did manage to write
> // a function composition function and we composed sum
> // and square, and we could call it and get a correct result.
>
>
> And this program demonstrates what happens if you try it in Swift 4:
>
> func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) ->
> (T) -> V {
> return { x in g(f(x)) }
> }
> func sum(_ a: Int, _ b: Int) -> Int { return a + b }
> func square(_ a: Int) -> Int { return a * a }
> // let squaredSum = compose(square, sum) // Error! (without the
> compose-variant below)
>
> // The error message is:
> // Cannot convert value of type `(Int, Int) -> Int` to
> // expected argument type `(_) -> _`
>
> // That's it, it is simply not possible!
>
> // You'd have to write special variants of the compose func for every
> combination
> // of parameter counts! For example, in order to get this sum and square
> // example working, this specific variant must be written:
> func compose(_ g: @escaping (V) -> W, _ f: @escaping (T, U) ->
> V) -> (T, U) -> W {
> return { (x, y) in g(f(x, y)) }
> }
> // Now it will work:
> let squaredSum = compose(square, sum)
> // But only thanks to that awfully specific compose func variant ...
> // We would have to write a lot more variants for it to be practically
> usable on pretty much any common function.
>
> I'm sure some will say:
> "no regular developers use function composition anyway so why ..."
> or
> "It's not very swifty to use free functions and higher order functions
> like that."
>
> My answer is that this is just a simple but telling example. The issue (as
> I see it) exists in all situations involving generics and function types.
>
> I'm a regular programmer and I like to be able to write basic, useful
> abstractions.
> It's no fun when the language forces you to write lots of specific
> variants of your generic code.
>
> I would feel less worried about the parentheses situation if the language
> was going in a direction where you could see how this simple exercise would
> be a no brainer.
>
> Can Swift's parentheses-situation be sorted out before ABI stability?
> Otherwise it would be a bit like if Swift had kept the special rule for
> the first parameter, only much worse.
>
>
> Out of curiosity, how do you think this would impa

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

[Jens Persson via swift-evolution]

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 have to special-case it for
every combination of parameter counts of f and g that it should be able to
handle.

The following program demonstrates how it can be done in Swift 3.1 and 3.2:

func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) ->
(T) -> V {
return { x in g(f(x)) }
}
func sum(_ a: Int, _ b: Int) -> Int { return a + b }
func square(_ a: Int) -> Int { return a * a }
let squaredSum = compose(square, sum)
let result = squaredSum((3, 4)) // A bit unexepected with a tuple here but
ok ...
print(result) // 49
// Well, it worked, not flawlessly but we did manage to write
// a function composition function and we composed sum
// and square, and we could call it and get a correct result.


And this program demonstrates what happens if you try it in Swift 4:

func compose(_ g: @escaping (U) -> V, _ f: @escaping (T) -> U) ->
(T) -> V {
return { x in g(f(x)) }
}
func sum(_ a: Int, _ b: Int) -> Int { return a + b }
func square(_ a: Int) -> Int { return a * a }
// let squaredSum = compose(square, sum) // Error! (without the
compose-variant below)

// The error message is:
// Cannot convert value of type `(Int, Int) -> Int` to
// expected argument type `(_) -> _`

// That's it, it is simply not possible!

// You'd have to write special variants of the compose func for every
combination
// of parameter counts! For example, in order to get this sum and square
// example working, this specific variant must be written:
func compose(_ g: @escaping (V) -> W, _ f: @escaping (T, U) ->
V) -> (T, U) -> W {
return { (x, y) in g(f(x, y)) }
}
// Now it will work:
let squaredSum = compose(square, sum)
// But only thanks to that awfully specific compose func variant ...
// We would have to write a lot more variants for it to be practically
usable on pretty much any common function.

I'm sure some will say:
"no regular developers use function composition anyway so why ..."
or
"It's not very swifty to use free functions and higher order functions like
that."

My answer is that this is just a simple but telling example. The issue (as
I see it) exists in all situations involving generics and function types.

I'm a regular programmer and I like to be able to write basic, useful
abstractions.
It's no fun when the language forces you to write lots of specific variants
of your generic code.

I would feel less worried about the parentheses situation if the language
was going in a direction where you could see how this simple exercise would
be a no brainer.

Can Swift's parentheses-situation be sorted out before ABI stability?
Otherwise it would be a bit like if Swift had kept the special rule for the
first parameter, only much worse.

/Jens




On Fri, Jun 9, 2017 at 7:17 PM, Gor Gyolchanyan  wrote:

> Yes, except why would you need to define `((A, B)) -> C`?, If you need to
> pass a 2-element tuple into a function that takes two parameters - you can!
> If you want to pass two values into a function that  *looks* like it takes
> a single 2-element tuple - you can! Seems to me that the difference between
> `((A, B)) -> C` and `(A, B) -> C` is virtually non-existent. But keep in
> mind that this only works for bare tuples (the ones that can't have
> labels). Non-closure functions DO have labels, which is part of their
> signature, so this is a different story.
>
> On Jun 9, 2017, at 6:18 PM, Gwendal Roué  wrote:
>
>
> Le 9 juin 2017 à 17:12, Gor Gyolchanyan via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
>
> So I wonder if any of you have had any thoughts about what Swift's
> parentheses-related future (or evolutionary baggage) will be?
>
>
> I really wish swift used the concept of tuples **exclusively** for all
> purposes that involve parentheses, as well as dividing tuples into two
> categories:
> - Bare tuples, which do not have labels.
> - Rich tuples, which do.
> As a consequence, here's a list of statements that would become true:
> - All functions take exactly one parameter, which is a tuple.
> - All closures (a.k.a. function pointers) take exactly one parameter,
> which is a bare tuple.
> - All functions return exactly one parameter, which is a tuple.
> - Pattern matching is done on a single bare tuple using a single bare
> tuple pattern.
>
> The currently ongoing proposal to make a single-element tuple auto-flatten
> would work extremely well with this idea, by making all these changes
> completely backward-compatible.
>
>
> If I have well understood, Swift has evolved away from this.
>
> If what you describe were true, added to the fact that there is no such
> thing as a one-element tuple in the language, then (A,B) -> C and ((A, B))
> -> C could not be distinguished, for the simple reason that (

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

[Jens Persson via swift-evolution]

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 proposals. Tuple splat (or rather the whole "universal tuple concept")
would certainly have been an extremely powerful and elegant feature (I
really can't understand why they decided to call it "cute" in the
proposal), if it had worked all the way, without creating inconsistencies
and questions (inout, variadics etc).

However, I don't see any other way forward than to properly implement
SE-0110 et al, and then work from there.

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

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

[Jens Persson via swift-evolution]

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
with even more inconsistencies.

FWIW I can't see how SE-0110 can be considered fully implemented, and this
is simply because the most recent compiler still cannot properly
"Distinguish between single-tuple and multiple-argument function types"
(that's the title of SE-0110), this is evident in lots of different ways,
here are some of them:

https://bugs.swift.org/browse/SR-5127
Single-tuple and multiple-argument function types should not be considered
equal

https://bugs.swift.org/browse/SR-5128
Don't allow swapping a single-tuple function with a multiple-argument
function

https://bugs.swift.org/browse/SR-5129
Don't treat func signatures as being the same when they are in fact
different

https://bugs.swift.org/browse/SR-5130
Single-tuple and multiple-argument function types should be treated as
different types

I think of the "regression"/decreased ergonomics as a price that is worth
paying for, and a necessary step towards, getting the language in a state
in which it is possible to get rid of Swift's current parentheses-related
inconsistencies and possibly reimplement the hopefully just temporarily
lost ergonomics and/or expressiveness.

Another related "regression" that I think is worth noting has to do with
generics, namely the inability to have type parameters for function types
in this form: Parameter -> Result. This is no longer possible in Swift 4
and it will instead require special casing for each number of parameters in
the function types. This means that it is also impossible to make a type
generic over just function types (wihtout special casing for parameter
count). These things were (sort of) possible to do in earlier versions, but
they couldn't make it all the way without other parts of the language
falling apart. They certainly hinted about something nice, and maybe if the
language is allowed to be simplified and made more consistent, they can be
reimplemented in a proper way.

/Jens


On Thu, Jun 8, 2017 at 3:26 PM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> On 08.06.2017 9:43, Jonathan Hull wrote:
>
>> Also, I want to repeat what I said on the other thread.  We should revert
>> to Swift 3 behavior for this, and then take the time to design the behavior
>> we really want (either for 4.1 or 5).  Anything else will cause us to break
>> people’s code twice…
>>
>
> Yes, *just* ignore/revert a number of connected, actively discussed and
> accepted, implemented(partially for some) proposals, freeze the current
> broken state of function types for very long period without any ability in
> near feature to fix it.
>
> Instead of improvement of the syntax of the problematic parts of code even
> after release (if not possible to suggest a suitable solution before the
> release). I don't think that *improvements* in syntax can break people's
> code.
>
> Huh..
>
>
>> Thanks,
>> Jon
>>
>> On Jun 7, 2017, at 11:50 AM, Gwendal Roué via swift-evolution <
>>> swift-evolution@swift.org > wrote:
>>>
>>>
>>>
>>> Le 7 juin 2017 à 20:33, Gwendal Roué >>> gwendal.r...@gmail.com>> a écrit :

 For example, take those three functions:

 func f(_ closure:(Int, Int) -> ())
 func g(_ closure:((Int, Int)) -> ())
 func h(_ closure:((a: Int, b: Int)) -> ())

 If one can always write (as in Swift 3):

 f { (a, b) in ... }
 g { (a, b) in ... }
 c { (a, b) in ... }

 Then one can easily deal with a badly fit closure signature.

 This is most examplified by dictionaries. They always expose (key: Key,
 value: Value) tuples (their Element type). Problem is that 'key' and
 'value' are identifiers that only matter for dictionaries, not for
 dictionary users. It's very important for dictionary users to forget about
 tuples, and the `key` and `value` words:

 // No pollution
 dictionary.map { (name, score) in ... }

>>>
>>> It looks like some people in this mailing list are horrified by this
>>> "request" (not a feature request, but a request that Swift 3 behavior is
>>> restored, actually).
>>>
>>> What could be the reasons for such a bad reaction?
>>>
>>> 1: measurable runtime overhead (slower programs in some cases, without
>>> any obvious way for the developper to notice where is the extra cost)
>>> 2: measurable compiler overhead (slower compilation)
>>> 3: implementation complexity (slower swift progress, technical debt,
>>> etc.)
>>> 4: other?
>>>
>>> I understand 1. We are all fascinated by C++ and Rust "zero-overhead".
>>> If this is the main concern of the community, then we may focus the
>>> discussion of that very precise topic.
>>>
>>> I can live with 2 (just a personal subj

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

[Jens Persson via swift-evolution]

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 posts):

  Exercise 1
Write a (generic) function composition operator in Swift 4
(working as expected for all function types).

  Exercise 2
Write a generic type WrappedFunction that can wrap any function in
Swift 4
(with type parameters for Input and Output).

When you have completed (or given up) the exercises, please note that once
in the history of Swift, these were simple tasks. You could come up with
working solutions very quickly without any boilerplate or special casing
(although perhaps not entirely without some of the parentheses-related
inconsistencies of that time).

I've been reporting a lot of parentheses-related bugs since the first Swift
beta, and I'm only getting more and more worried that the current
incremental approach to fixing these is not working very well, resulting in
a language that is more complex and less expressive than it could be.

Discussions often seem to end up being a bit too focused on particular use
cases and details, and less on how everything fit together as a system.


So I wonder if any of you have had any thoughts about what Swift's
parentheses-related future (or evolutionary baggage) will be?


PS

My perhaps unpopular thoughts:

I wish the parentheses-related parts of Swift could be carefully evaluated
and redesigned from scratch, as a whole, in order to arrive at a solution
that is as simple and expressive as possible.

But perhaps this has already happened and we are now just taking some steps
back that are necessary for reimplementing some of the good stuff (that has
been - at least IMHO - sort of hinted in earlier versions of Swift). But it
feels like there is not enough time ...

Swift, please break my code all you want before it's too late, as long as
it results in increased (rather than decreased) consistency, simplicity,
expressiveness, optimizability and safety. Otherwise I could have used
Objective C++.

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

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

[Jens Persson via swift-evolution]

Here are the four you asked me to report:

https://bugs.swift.org/browse/SR-5127
Single-tuple and multiple-argument function types should not be considered
equal

https://bugs.swift.org/browse/SR-5128
Don't allow swapping a single-tuple function with a multiple-argument
function

https://bugs.swift.org/browse/SR-5129
Don't treat func signatures as being the same when they are in fact
different

https://bugs.swift.org/browse/SR-5130
Single-tuple and multiple-argument function types should be treated as
different types

/Jens


On Tue, Jun 6, 2017 at 8:17 PM, Mark Lacey via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jun 6, 2017, at 11:09 AM, Vladimir.S  wrote:
> >
> > On 06.06.2017 19:41, Mark Lacey wrote:
> >>> On Jun 6, 2017, at 4:00 AM, Vladimir.S  sva...@gmail.com>> wrote:
> >>>
> >>> Mark, could you please also comment this inconsistencies / bugs :
> >>> (swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-01-a-osx)
> >>>
> >>> func fooParam(_ x: Int, _ y: Int){}
> >>> func fooTuple(_ x: (Int, Int)) {}
> >>>
> >>> print("type of fooParam is", type(of:fooParam))
> >>> // result: type of fooParam is (Int, Int) -> ()
> >>>
> >>> print("type of fooTuple is", type(of:fooTuple))
> >>> // result: type of fooTuple is (Int, Int) -> ()
> >>>
> >>> print("type of fooTuple as (_:(Int,Int))->Void is", type(of: fooTuple
> as (_:(Int,Int))->()))
> >>> // result: type of fooTuple as (_:(Int,Int))->() is (Int, Int) -> ()
> >>>
> >>>
> >>> print("type of fooParam == type of fooTuple ?", type(of: fooParam) ==
> type(of: fooTuple))
> >>> // result: true
> >>>
> >>> if fooParam is (_: (Int,Int))->() { print("fooParam is (_:
> (Int,Int))->()") }
> >>> // result: fooParam is (_: (Int,Int))->()
> >>>
> >>> if fooTuple is (Int,Int)->() { print("fooTuple is (Int,Int)->()") }
> >>> // result: fooTuple is (Int,Int)->()
> >>>
> >>> var closureParam = { (x: Int, y: Int) in  }
> >>> var closureTuple = { (x: (Int, Int)) in  }
> >>>
> >>> print("type of closureParam is", type(of:closureParam))
> >>> // result: type of closureParam is (Int, Int) -> ()
> >>>
> >>> print("type of closureTuple is", type(of:closureTuple))
> >>> // result: type of closureTuple is (Int, Int) -> ()
> >>>
> >>> if closureParam is (_: (Int,Int))->() { print("closureParam is (_:
> (Int,Int))->()") }
> >>> // result: closureParam 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 <http://bugs.swift.org>,
> one for the ‘is’ issue, and one for type(of:)?
> >> These (along with the issue with function declarations that Jens
> mentioned) are all similar issues, but each is in a different part of the
> compiler.
> >
> > Here they are:
> > https://bugs.swift.org/browse/SR-5114  (typeof)
> > https://bugs.swift.org/browse/SR-5112  (is)
>
> Thanks!
>
> Mark
>
> >
> >> Mark
> >>>
> >>> Thank you.
> >>> Vladimir.
> >>>
> >>> On 06.06.2017 11:43, Mark Lacey via swift-evolution wrote:
> >>>>> On Jun 6, 2017, at 12:08 AM, Jens Persson via swift-evolution <
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>  swift-evolution@swift.org>> wrote:
> >>>>>
> >>>>> IMHO There seems to be a lot of bugs and inconsistencies left in
> more than just the reflective type system, for example the following won't
> compile although the two foo funcs clearly take different types as argument:
> >>>>>
> >>>>> func foo(fun: (Int, Int) -> ()) { print("was given a function of
> type: (Int, Int) -> ()") }
> >>>>> func foo(fun: ((Int, Int)) -> ()) { print("was given a function of
> type: ((Int, Int)) -> ()") }
> >>>> I took a look at this. When determining if we have conflicting
> declarations, we compute an interface type and this computation is
> stripping the parens around the tuple in the second example, resulting in
> these two signatures appearing to be the same, despite the fact that the

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

[Jens Persson via swift-evolution]

IMHO There seems to be a lot of bugs and inconsistencies left in more than
just the reflective type system, for example the following won't compile
although the two foo funcs clearly take different types as argument:

func foo(fun: (Int, Int) -> ()) { print("was given a function of type:
(Int, Int) -> ()") }
func foo(fun: ((Int, Int)) -> ()) { print("was given a function of type:
((Int, Int)) -> ()") }

// This will result in error: invalid redeclaration of 'foo(fun:)'

I would expect this to compile, and I can't understand how this has
anything to do with the reflective type system.


Here is another example:

func add(_ a: Int, _ b: Int) -> Int { return a + b }
let a: (Int, Int) -> Int = add
let b: ((Int, Int)) -> Int = add // This is OK, unexpectedly

I would not expect it to compile since the add func does not have the type
((Int, Int)) -> Int.
I don't think that is a dynamic cast, is it?

/Jens




On Tue, Jun 6, 2017 at 2:45 AM, John McCall  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 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),
>
>
> Gaps in the reflective type system are bugs, but they are not showstopper
> bugs.  We do not even expose any way to query the reflective system today;
> it basically only affects type equality and dynamic casts that programmers
> are very unlikely to use.  The changes in call type-checking are vastly
> more important, are implemented (modulo bugs, of course), and by themselves
> warrant calling SE-0110 implemented.
>
> John.
>
>
> And yet:
>
> 1. The status of SE-0110 is "Implemented"
>
> 2. These statuses of the following issues are "resolved":
> SR-2008: Distinguish between single-tuple and multiple-argument
> function types
> SR-2216: Confusing behavior related to closure types and tuples
> SR-296: Fix inconsistencies related to tuples, arg/param lists, type
> params, typealiases
>
> Why?
>
> /Jens
>
>
> On Sun, Jun 4, 2017 at 5:49 PM, Ben Rimmington 
> wrote:
>
>> I assumed that Swift 3 mode would be the default, so that existing
>> `#!/usr/bin/swift` scripts continue to work.
>>
>> -- Ben
>>
>> > On 3 Jun 2017, at 23:47, Jens Persson  wrote:
>> >
>> > 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 language mode?
>> >>
>> >> <https://swift.org/blog/swift-4-0-release-process/#source-co
>> mpatibility>
>> >>
>> >> -- Ben
>>
>
> ___
> 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] Why is the status of SE-0110 "implemented"?

[Jens Persson via swift-evolution]

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 statuses of the following issues are "resolved":
SR-2008: Distinguish between single-tuple and multiple-argument
function types
SR-2216: Confusing behavior related to closure types and tuples
SR-296: Fix inconsistencies related to tuples, arg/param lists, type
params, typealiases

Why?

/Jens


On Sun, Jun 4, 2017 at 5:49 PM, Ben Rimmington  wrote:

> I assumed that Swift 3 mode would be the default, so that existing
> `#!/usr/bin/swift` scripts continue to work.
>
> -- Ben
>
> > On 3 Jun 2017, at 23:47, Jens Persson  wrote:
> >
> > 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 language mode?
> >>
> >>  >
> >>
> >> -- Ben
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jens Persson via swift-evolution]

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 language mode?
>
> 
>
> -- Ben
>
> > On 3 Jun 2017, at 23:01, Jens Persson wrote:
> >
> > 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 and multiple-argument function types"
> >
> > Keep that in mind while observing the following demonstration of the
> (Swift 4) behavior of Developer Snapshot 2017-06-02 (a):
> >
> > func f(_ a: Int, _ b: Int) { print("\(a), \(b)") }
> > func g(_ tuple: (Int, Int)) { print("\(tuple)") }
> > f(1, 2) // 1, 2
> > g((1, 2)) // (1, 2)
> > // Working as expected.
> >
> > // But:
> > print(type(of: f) == type(of: g)) // true
> > // IMHO this is not how to properly
> > // "Distinguish between single-tuple and multiple-argument function
> types"
> >
> > // And as if that wasn't enough (pay close attention):
> > var (fCopy, gCopy) = (f, g)
> > fCopy(1, 2) // 1, 2
> > gCopy((1, 2)) // (1, 2)
> > swap(&fCopy, &gCopy)
> > fCopy(1, 2) // (1, 2)
> > gCopy((1, 2)) // 1, 2
> > // Crazy!
> >
> > I'm trying to put this behavior and the following pieces together:
> >
> > 1. The introdoction from SE-0110:
> > "Swift's type system should properly distinguish between functions that
> take one tuple argument, and functions that take multiple arguments."
> >
> > 2. The status of SE-0110:
> > Implemented (Swift 4)
> >
> > 3. The "fixed as part of implementing SE-0110" notification of my bug
> reports
> > SR-2216: Confusing behavior related to closure types and tuples
> > SR-296: Fix inconsistencies related to tuples, arg/param lists, type
> params, typealiases
> >
> >
> > Perhaps SE-0110 is just not fully implemented in dev snapshot
> 2017-06-02, but it is implemented somewhere, why else should it get the
> status "implemented"?
> >
> > But then I read the following by Vladimir S (one of the SE-0110
> authors?):
> > https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20170529/036965.html
> >
> > It's a very interesting read, and it's nice to see these old
> inconsistencies are getting some attention (they deserve all the attention
> they can get), but I'm still confused.
> >
> > Is it possible to implement SE-0110 without sorting out the above
> demonstrated inconsistencies?
> >
> > Should status of SE-0110 really be "Implemented"?
> >
> > /Jens
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jens Persson via swift-evolution]

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 and multiple-argument function types"

Keep that in mind while observing the following demonstration of the (Swift
4) behavior of Developer Snapshot 2017-06-02 (a):

func f(_ a: Int, _ b: Int) { print("\(a), \(b)") }
func g(_ tuple: (Int, Int)) { print("\(tuple)") }
f(1, 2) // 1, 2
g((1, 2)) // (1, 2)
// Working as expected.

// But:
print(type(of: f) == type(of: g)) // true
// IMHO this is not how to properly
// "Distinguish between single-tuple and multiple-argument function types"

// And as if that wasn't enough (pay close attention):
var (fCopy, gCopy) = (f, g)
fCopy(1, 2) // 1, 2
gCopy((1, 2)) // (1, 2)
swap(&fCopy, &gCopy)
fCopy(1, 2) // (1, 2)
gCopy((1, 2)) // 1, 2
// Crazy!

I'm trying to put this behavior and the following pieces together:

1. The introdoction from SE-0110:
"Swift's type system should properly distinguish between functions that
take one tuple argument, and functions that take multiple arguments."

2. The status of SE-0110:
Implemented (Swift 4)

3. The "fixed as part of implementing SE-0110" notification of my bug
reports
SR-2216: Confusing behavior related to closure types and tuples
SR-296: Fix inconsistencies related to tuples, arg/param lists, type
params, typealiases


Perhaps SE-0110 is just not fully implemented in dev snapshot 2017-06-02,
but it is implemented somewhere, why else should it get the status
"implemented"?

But then I read the following by Vladimir S (one of the SE-0110 authors?):
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036965.html

It's a very interesting read, and it's nice to see these old
inconsistencies are getting some attention (they deserve all the attention
they can get), but I'm still confused.

Is it possible to implement SE-0110 without sorting out the above
demonstrated inconsistencies?

Should status of SE-0110 really be "Implemented"?

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

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

[Jens Persson via swift-evolution]

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,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E
)
subscript(x: Int, y: Int) -> E {
get {
// No index out of bounds check
var m = self // <-- This workaround will be optimized away.
return withUnsafeBytes(of: &m) {
let byteOffset = MemoryLayout.stride * (x + y*19)
return $0.load(fromByteOffset: byteOffset, as: E.self)
}
}
set {
withUnsafeMutableBytes(of: &self) {
let byteOffset = MemoryLayout.stride * (x + y*19)
$0.storeBytes(of: newValue, toByteOffset: byteOffset, as:
E.self)
}
}
}
}

It isn't pretty but it works (haven't tried this code example though, but
you get the idea).


I wish it was possible to write something like
struct StaticArray {
...
}
instead (a statically allocated array with type-level Count as well as
Element).

/Jens


On Mon, Apr 17, 2017 at 7:52 PM, Anders Kierulf via swift-evolution <
swift-evolution@swift.org> wrote:

> Swift needs a datatype that contains a fixed number of a given type;
> basically a simple fixed-size array.
>
> Motivation: I’ve been porting code for Monte Carlo Tree Search in my
> Go-playing program from C++ to Swift. Performance is crucial for this code,
> as more simulations lead to better play. After the initial port, the Swift
> code was more than 10x slower than my C++ code. After several weeks of
> optimizing, profiling, and digging through disassembly, I’ve gotten to
> within a factor of 2. Most of that gain came from using the ugly workaround
> of importing fixed-size arrays from C.
>
> My app is designed for a 19x19 (or smaller) Go board, not an arbitrary N x
> N board, so I don’t want to pay the high cost of variable-size data
> structures in the lowest levels of my app. Most apps are not like this, and
> most of my app is not, but this kernel of my app needs to be fast. Heap
> allocations, reference counting, and indirections all slow down the code. I
> just need a fixed size of memory that I can access like an array, and Swift
> doesn’t let me do that.
>
> Workaround: By importing an array from C, I can allocate a blob of memory
> on the stack or include it in a struct. I can then use UnsafeRawPointer to
> access that blob like an array (see details in SR-4548). This is ugly, but
> it works, and it is much faster than using a Swift array. However, I’m
> stymied by SR-4542, which causes mutability to spread like a plague through
> client code.
>
> (SR-4542: Calling a function taking an UnsafeRawPointer forces the
> parameter to be passed as inout, which means the method must be mutating.
> UnsafeMutableRawPointer should require inout, UnsafeRawPointer should not.)
>
> Proposal: UnsafeMutablePointer almost provides what I need. However, it
> can only allocate memory on the heap, or it can take a given blob of memory
> and interpret it as something else. What’s missing is a way to allocate
> typed memory of a certain size on the stack or in a struct. For example,
> something like this, with support for subscripts, limited to value types:
>
> var foo = UnsafeMemory(count: 6)
> or
> var bar = FixedSizeArray(repeating: 0, count: 380)
>
> Alternatives:
> (1) C arrays are currently imported as tuples, so extending tuples with
> subscripts and adding a way to create tuples with a specific count of the
> same type could address this need. However, I don’t think this fits well
> with the concept of tuples.
> (2) Changing the Array type to allow a fixed size could be considered in
> the future. ‘count’ and ‘capacity’ would be fixed and only known to the
> c

Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

[Jens Persson via swift-evolution]

Strong +1

On Sat, Sep 24, 2016 at 9:36 AM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
>- What is your evaluation of the proposal?
>
> +1, like others I would love to have this feature available today, as my
> code is currently littered with complicated constraints on types that could
> be much more elegantly handled by constraints on the associated types
> themselves.
>
>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Definitely, this seems like an important next step for Swift's support of
> generics and constraints.
>
>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Yes, absolutely.
>
>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> I've read through it fairly quickly, but I feel I already have a pretty
> good grasp of what the feature entails as it solves a problem I encounter
> often!
>
> ___
> 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] generic associatedtype?

[Jens Persson via swift-evolution]

And a simple example of what the code might look like when using it:
https://gist.github.com/anonymous/790a690597069fe70b8c874a042d52d0

On Tue, Sep 20, 2016 at 6:47 PM, Jens Persson  wrote:

> Here's the code for the little meta-programming tool, SwiftInSwift:
> https://gist.github.com/anonymous/07d9df1a80820bb5abf5a2c671fd223f
> /Jens
>
> On Tue, Sep 20, 2016 at 6:28 PM, Jens Persson  wrote:
>
>> You can put DEF-blocks and PRINT-blocks in your code, eg:
>>
>> // DEF-{
>> func generateSomeCode() -> [String] {
>> var linesOfCode = [String]()
>> // ... fill linesOfCode with some interesting code ...
>> return linesOfCode
>> }
>> // }-DEF
>>
>> // PRINT-{ generateSomeCode()
>> // The result of the print-block-expression will
>> // replace these lines when cmd+B is pressed.
>> // }-PRINT
>>
>> When you press cmd+B, the meta-programming-tool will put together a Swift
>> script of the DEF-blocks and PRINT-block-expressions, and evaluate the
>> expressions of the PRINT-blocks, which 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  wrote:
>>
>>> On 20.09.2016 16:43, Jens Persson via swift-evolution wrote:
>>>
>>>> Sure, but the reason to go for C++ in this case would only be to be
>>>> able to
>>>> use eg its templates and constexprs, things that doesn't translate well
>>>> into Swift. And I think it's a long term goal of Swift to become a
>>>> systems
>>>> language.
>>>>
>>>> We ended up making a meta-programming-tool that we use as a Build Phase,
>>>> before compilation, that lets us write code-generating Swift code,
>>>> within
>>>> our ordinary Swift code. (A bit like GYB but Swift-only, using just
>>>> regular
>>>> Swift within our regular Swift source files.)
>>>>
>>>> This DIY meta programming facility let's us overcome the current
>>>> limitations of Swift's type system in a somewhat convenient/nice way.
>>>>
>>>
>>> Very interesting. Could you share some examples of how your source code
>>> looks like(this "code-generating Swift code") and what is produced by this
>>> "meta-programming-tool" ?
>>>
>>>
>>>> /Jens
>>>>
>>>>
>>>> On Mon, Sep 19, 2016 at 10:07 PM, Goffredo Marocchi >>> <mailto:pana...@gmail.com>> wrote:
>>>>
>>>> If you have to compromise that much, it makes for a very compelling
>>>> case to go for C++ wrapped in Objective-C(++) as far as that
>>>> section of
>>>> the code is concerned and call it from Swift using the already
>>>> provided
>>>> bridging support.
>>>>
>>>> I do not think anyone will question the purity of our bodily
>>>> fluids/minds if we do not write 100% of code in Swift :), support
>>>> for
>>>> interoperability with other languages is there for a reason IMHO and
>>>> should be expanded and not begrudged.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 19 Sep 2016, at 14:14, Jens Persson via swift-evolution
>>>> mailto:swift-evolution@swift.org>>
>>>> wrote:
>>>>
>>>> Ok, thanks! I take it that we should not expect any dramatic
>>>>> advances
>>>>> of Swift's type system any time soon.
>>>>>
>>>>> Reason for asking is that we are trying to write an API for
>>>>> N-dimensional graphics/audio/signal/data processing.
>>>>>
>>>>> Metal, vDSP, simd, etc. would perhaps be used, but only behind the
>>>>> scenes, eventually, as necessary, since we want something more
>>>>> uniform and math-like, thus allowing for a more rapid experimental
>>>>> style of coding, where you can quickly try something out for a
>>>>> different number of dimensions, etc.
>>>>>
>>>>> This has turned out to be impossibly hard to write in current
>>>>> Swift,
>>>>> unless you are willing to either
>>>>>
>>>>> 1. Forget about performance and type safety, ie use a standard
>>&

Re: [swift-evolution] generic associatedtype?

[Jens Persson via swift-evolution]

Here's the code for the little meta-programming tool, SwiftInSwift:
https://gist.github.com/anonymous/07d9df1a80820bb5abf5a2c671fd223f
/Jens

On Tue, Sep 20, 2016 at 6:28 PM, Jens Persson  wrote:

> You can put DEF-blocks and PRINT-blocks in your code, eg:
>
> // DEF-{
> func generateSomeCode() -> [String] {
> var linesOfCode = [String]()
> // ... fill linesOfCode with some interesting code ...
> return linesOfCode
> }
> // }-DEF
>
> // PRINT-{ generateSomeCode()
> // The result of the print-block-expression will
> // replace these lines when cmd+B is pressed.
> // }-PRINT
>
> When you press cmd+B, the meta-programming-tool will put together a Swift
> script of the DEF-blocks and PRINT-block-expressions, and evaluate the
> expressions of the PRINT-blocks, which 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  wrote:
>
>> On 20.09.2016 16:43, Jens Persson via swift-evolution wrote:
>>
>>> Sure, but the reason to go for C++ in this case would only be to be able
>>> to
>>> use eg its templates and constexprs, things that doesn't translate well
>>> into Swift. And I think it's a long term goal of Swift to become a
>>> systems
>>> language.
>>>
>>> We ended up making a meta-programming-tool that we use as a Build Phase,
>>> before compilation, that lets us write code-generating Swift code, within
>>> our ordinary Swift code. (A bit like GYB but Swift-only, using just
>>> regular
>>> Swift within our regular Swift source files.)
>>>
>>> This DIY meta programming facility let's us overcome the current
>>> limitations of Swift's type system in a somewhat convenient/nice way.
>>>
>>
>> Very interesting. Could you share some examples of how your source code
>> looks like(this "code-generating Swift code") and what is produced by this
>> "meta-programming-tool" ?
>>
>>
>>> /Jens
>>>
>>>
>>> On Mon, Sep 19, 2016 at 10:07 PM, Goffredo Marocchi >> <mailto:pana...@gmail.com>> wrote:
>>>
>>> If you have to compromise that much, it makes for a very compelling
>>> case to go for C++ wrapped in Objective-C(++) as far as that section
>>> of
>>> the code is concerned and call it from Swift using the already
>>> provided
>>> bridging support.
>>>
>>> I do not think anyone will question the purity of our bodily
>>> fluids/minds if we do not write 100% of code in Swift :), support for
>>> interoperability with other languages is there for a reason IMHO and
>>> should be expanded and not begrudged.
>>>
>>> Sent from my iPhone
>>>
>>> On 19 Sep 2016, at 14:14, Jens Persson via swift-evolution
>>> mailto:swift-evolution@swift.org>>
>>> wrote:
>>>
>>> Ok, thanks! I take it that we should not expect any dramatic advances
>>>> of Swift's type system any time soon.
>>>>
>>>> Reason for asking is that we are trying to write an API for
>>>> N-dimensional graphics/audio/signal/data processing.
>>>>
>>>> Metal, vDSP, simd, etc. would perhaps be used, but only behind the
>>>> scenes, eventually, as necessary, since we want something more
>>>> uniform and math-like, thus allowing for a more rapid experimental
>>>> style of coding, where you can quickly try something out for a
>>>> different number of dimensions, etc.
>>>>
>>>> This has turned out to be impossibly hard to write in current Swift,
>>>> unless you are willing to either
>>>>
>>>> 1. Forget about performance and type safety, ie use a standard Array
>>>> (instead of a static vector with type-level Count as well as
>>>> Element)
>>>> for N-dimensional positions, matrices, vectors, indices, etc.
>>>>
>>>> 2. Forget about code reuse / abstractions.
>>>>
>>>> Option 1 is not an alternative. We want to let the compiler (and our
>>>> code) know/optimize as much as possible, otherwise it will be
>>>> unusably slow even for ("rapid") prototyping.
>>>>
>>>> So we'll probably go with option 2 and spell out / generate code for
>>>> 

Re: [swift-evolution] generic associatedtype?

[Jens Persson via swift-evolution]

You can put DEF-blocks and PRINT-blocks in your code, eg:

// DEF-{
func generateSomeCode() -> [String] {
var linesOfCode = [String]()
// ... fill linesOfCode with some interesting code ...
return linesOfCode
}
// }-DEF

// PRINT-{ generateSomeCode()
// The result of the print-block-expression will
// replace these lines when cmd+B is pressed.
// }-PRINT

When you press cmd+B, the meta-programming-tool will put together a Swift
script of the DEF-blocks and PRINT-block-expressions, and evaluate the
expressions of the PRINT-blocks, which 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  wrote:

> On 20.09.2016 16:43, Jens Persson via swift-evolution wrote:
>
>> Sure, but the reason to go for C++ in this case would only be to be able
>> to
>> use eg its templates and constexprs, things that doesn't translate well
>> into Swift. And I think it's a long term goal of Swift to become a systems
>> language.
>>
>> We ended up making a meta-programming-tool that we use as a Build Phase,
>> before compilation, that lets us write code-generating Swift code, within
>> our ordinary Swift code. (A bit like GYB but Swift-only, using just
>> regular
>> Swift within our regular Swift source files.)
>>
>> This DIY meta programming facility let's us overcome the current
>> limitations of Swift's type system in a somewhat convenient/nice way.
>>
>
> Very interesting. Could you share some examples of how your source code
> looks like(this "code-generating Swift code") and what is produced by this
> "meta-programming-tool" ?
>
>
>> /Jens
>>
>>
>> On Mon, Sep 19, 2016 at 10:07 PM, Goffredo Marocchi > <mailto:pana...@gmail.com>> wrote:
>>
>> If you have to compromise that much, it makes for a very compelling
>> case to go for C++ wrapped in Objective-C(++) as far as that section
>> of
>> the code is concerned and call it from Swift using the already
>> provided
>> bridging support.
>>
>> I do not think anyone will question the purity of our bodily
>> fluids/minds if we do not write 100% of code in Swift :), support for
>> interoperability with other languages is there for a reason IMHO and
>> should be expanded and not begrudged.
>>
>> Sent from my iPhone
>>
>> On 19 Sep 2016, at 14:14, Jens Persson via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> Ok, thanks! I take it that we should not expect any dramatic advances
>>> of Swift's type system any time soon.
>>>
>>> Reason for asking is that we are trying to write an API for
>>> N-dimensional graphics/audio/signal/data processing.
>>>
>>> Metal, vDSP, simd, etc. would perhaps be used, but only behind the
>>> scenes, eventually, as necessary, since we want something more
>>> uniform and math-like, thus allowing for a more rapid experimental
>>> style of coding, where you can quickly try something out for a
>>> different number of dimensions, etc.
>>>
>>> This has turned out to be impossibly hard to write in current Swift,
>>> unless you are willing to either
>>>
>>> 1. Forget about performance and type safety, ie use a standard Array
>>> (instead of a static vector with type-level Count as well as Element)
>>> for N-dimensional positions, matrices, vectors, indices, etc.
>>>
>>> 2. Forget about code reuse / abstractions.
>>>
>>> Option 1 is not an alternative. We want to let the compiler (and our
>>> code) know/optimize as much as possible, otherwise it will be
>>> unusably slow even for ("rapid") prototyping.
>>>
>>> So we'll probably go with option 2 and spell out / generate code for
>>> each and every permutation of
>>> (dim, data-structure, function/algorithm), and sadly this will also
>>> be necessary for every piece of code that uses the API, since it is
>>> impossible to write eg
>>>
>>> A generic StaticVector type with type parameters for its Count and
>>> Element.
>>>
>>> A generic N-dimensional array type with type parameters for its
>>> (NDim)Index: StaticVector (where Index.Element == Int)
>>> and
>>> Element
>>>
>>> Or we'll have to use (Obj) C++ : /
>>>

Re: [swift-evolution] generic associatedtype?

[Jens Persson via swift-evolution]

Sure, but the reason to go for C++ in this case would only be to be able to
use eg its templates and constexprs, things that doesn't translate well
into Swift. And I think it's a long term goal of Swift to become a systems
language.

We ended up making a meta-programming-tool that we use as a Build Phase,
before compilation, that lets us write code-generating Swift code, within
our ordinary Swift code. (A bit like GYB but Swift-only, using just regular
Swift within our regular Swift source files.)

This DIY meta programming facility let's us overcome the current
limitations of Swift's type system in a somewhat convenient/nice way.

/Jens


On Mon, Sep 19, 2016 at 10:07 PM, Goffredo Marocchi 
wrote:

> If you have to compromise that much, it makes for a very compelling case
> to go for C++ wrapped in Objective-C(++) as far as that section of the code
> is concerned and call it from Swift using the already provided bridging
> support.
>
> I do not think anyone will question the purity of our bodily fluids/minds
> if we do not write 100% of code in Swift :), support for interoperability
> with other languages is there for a reason 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 system any time soon.
>
> Reason for asking is that we are trying to write an API for N-dimensional
> graphics/audio/signal/data processing.
>
> Metal, vDSP, simd, etc. would perhaps be used, but only behind the scenes,
> eventually, as necessary, since we want something more uniform and
> math-like, thus allowing for a more rapid experimental style of coding,
> where you can quickly try something out for a different number of
> dimensions, etc.
>
> This has turned out to be impossibly hard to write in current Swift,
> unless you are willing to either
>
> 1. Forget about performance and type safety, ie use a standard Array
> (instead of a static vector with type-level Count as well as Element) for
> N-dimensional positions, matrices, vectors, indices, etc.
>
> 2. Forget about code reuse / abstractions.
>
> Option 1 is not an alternative. We want to let the compiler (and our code)
> know/optimize as much as possible, otherwise it will be unusably slow even
> for ("rapid") prototyping.
>
> So we'll probably go with option 2 and spell out / generate code for each
> and every permutation of
> (dim, data-structure, function/algorithm), and sadly this will also be
> necessary for every piece of code that uses the API, since it is impossible
> to write eg
>
> A generic StaticVector type with type parameters for its Count and Element.
>
> A generic N-dimensional array type with type parameters for its
> (NDim)Index: StaticVector (where Index.Element == Int)
> and
> Element
>
> Or we'll have to use (Obj) C++ : /
>
> /Jens
>
>
>
> On Mon, Sep 19, 2016 at 3:22 AM, Robert Widmann 
> wrote:
>
>>
>> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> 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 : CountType {
>> typealias Storage = (E)
>> ...
>> }
>> struct Count2 : CountType {
>> typealias Storage = (E, E)
>> ...
>> }
>> struct Count3 : CountType {
>> typealias Storage = (E, E, E)
>> ...
>> }
>> ...
>> protocol StaticArrayType {
>> associatedtype Count: CountType
>> associatedtype Element
>> ...
>> }
>> struct StaticArray : StaticArrayType {
>> typealias Count = C
>> var storage: C.Storage
>> ...
>> }
>>
>>
>>
>> Would adding support for generic associatedtypes be possible? Are there
>> any plans for it?
>>
>>
>> Possible, yes, plans, no.
>>
>> Generic associated types go part and parcel with higher-kinded
>> quantification and higher-kinded types, the implementation challenges of
>> which have been discussed thoroughly on this list and elsewhere.  Is there
>> a particular flavor you had in mind?
>>
>> One major problem is that presumably you’d want to constrain such a
>> generic a

Re: [swift-evolution] generic associatedtype?

[Jens Persson via swift-evolution]

Ok, thanks! I take it that we should not expect any dramatic advances of
Swift's type system any time soon.

Reason for asking is that we are trying to write an API for N-dimensional
graphics/audio/signal/data processing.

Metal, vDSP, simd, etc. would perhaps be used, but only behind the scenes,
eventually, as necessary, since we want something more uniform and
math-like, thus allowing for a more rapid experimental style of coding,
where you can quickly try something out for a different number of
dimensions, etc.

This has turned out to be impossibly hard to write in current Swift, unless
you are willing to either

1. Forget about performance and type safety, ie use a standard Array
(instead of a static vector with type-level Count as well as Element) for
N-dimensional positions, matrices, vectors, indices, etc.

2. Forget about code reuse / abstractions.

Option 1 is not an alternative. We want to let the compiler (and our code)
know/optimize as much as possible, otherwise it will be unusably slow even
for ("rapid") prototyping.

So we'll probably go with option 2 and spell out / generate code for each
and every permutation of
(dim, data-structure, function/algorithm), and sadly this will also be
necessary for every piece of code that uses the API, since it is impossible
to write eg

A generic StaticVector type with type parameters for its Count and Element.

A generic N-dimensional array type with type parameters for its
(NDim)Index: StaticVector (where Index.Element == Int)
and
Element

Or we'll have to use (Obj) C++ : /

/Jens



On Mon, Sep 19, 2016 at 3:22 AM, Robert Widmann 
wrote:

>
> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 : CountType {
> typealias Storage = (E)
> ...
> }
> struct Count2 : CountType {
> typealias Storage = (E, E)
> ...
> }
> struct Count3 : CountType {
> typealias Storage = (E, E, E)
> ...
> }
> ...
> protocol StaticArrayType {
> associatedtype Count: CountType
> associatedtype Element
> ...
> }
> struct StaticArray : StaticArrayType {
> typealias Count = C
> var storage: C.Storage
> ...
> }
>
>
>
> Would adding support for generic associatedtypes be possible? Are there
> any plans for it?
>
>
> Possible, yes, plans, no.
>
> Generic associated types go part and parcel with higher-kinded
> quantification and higher-kinded types, the implementation challenges of
> which have been discussed thoroughly on this list and elsewhere.  Is there
> a particular flavor you had in mind?
>
> One major problem is that presumably you’d want to constrain such a
> generic associatedtype and then we’d have to have some kind of
> type-level-yet-runtime-relevant apply of a generic witness table to
> another potentially generic witness.  It’s not clear what that kind of
> thing would look like, or how far it would have to be taken to get the kind
> of support you would expect from a basic implementation higher
> associatedtypes.  Implementations in languages like Haskell tend to also be
> horrendously inefficient - I believe Edward Kmett calls is the “Mother May
> I” effect of forcing a witness table to indirect through multiple layers of
> the witness because inlining necessarily fails for the majority of these
> things in the MTL.
>
> tl;dr Basic examples like the ones you cite hide the kinds of tremendously
> evil fun things you can do once you have these kinds of features.
>
>
> (
> I tried searching for it but I found only this:
> https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20160411/015089.html
> )
>
> Thanks,
> /Jens
>
> ___
> 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] generic associatedtype?

[Jens Persson via swift-evolution]

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 : CountType {
typealias Storage = (E)
...
}
struct Count2 : CountType {
typealias Storage = (E, E)
...
}
struct Count3 : CountType {
typealias Storage = (E, E, E)
...
}
...
protocol StaticArrayType {
associatedtype Count: CountType
associatedtype Element
...
}
struct StaticArray : StaticArrayType {
typealias Count = C
var storage: C.Storage
...
}



Would adding support for generic associatedtypes be possible? Are there any
plans for it?

(
I tried searching for it but I found only this:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/015089.html
)

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

Re: [swift-evolution] [Discussion] Parentheses

[Jens Persson via swift-evolution]

Thank you all, I guess it's impossible / very hard to come up with a design
without such inconsistencies and ambiguities, especially when parentheses
are used for so many different things in the language.
/Jens

On Thu, Jul 7, 2016 at 10:33 PM, Anton Zhilin 
wrote:

> I guess you are suggesting to:
> 1. Add single-element tuples to the language (not convertible to "plain"
> types)
> 2. Make all otherwise unnecessary parentheses signify single-element tuples
>
> In my first answer, I mentioned Haskell, because it treats types and
> variables in pretty much the same way.
> In that context, it is consistent to allow "extra" parentheses in types.
> Compare:
>
> a + (b!) vs A -> (B?)
>
> Both are not the best code style, but both are allowed. I see how
> separating single-element tuples solves one inconsistency, but notice how
> it creates another one.
> Of course, we are discussing Swift, not Haskell, and here we may want to
> go the other way and disallow extra parentheses on types. I don't really
> like that way, though.
>
> P.S. Since we now allow converting types 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 via swift-evolution <
> swift-evolution@swift.org>:
>
>> Also, regarding the special case of single element tuples, ie Int being
>> the same type as (Int) and Int))):
>> I'm wondering if that can be viewed as an irregularity baked in at the
>> foundation of the system (parenthesized expressions), sending ripples of
>> perhaps needless complexity through the rest of the (parentheses-using
>> parts) of the language. I'm not knowledgable enough to analyze this myself
>> though.
>> /Jens
>>
>>
>> On Thu, Jul 7, 2016 at 5:01 PM, Jens Persson  wrote:
>>
>>> As previously mentioned, I was talking about using those symbols only as
>>> a thinking-tool to possibly simplify language design, making the "real"
>>> differences and similarities easier to see while thinking about the design.
>>> The final syntax could perhaps still use normal parentheses for all
>>> these parts of the language. Please reread my previous two posts for more
>>> details.
>>> /Jens
>>>
>>>
>>> On Thursday, July 7, 2016, Vladimir.S  wrote:
>>>
>>>> On 06.07.2016 22:37, Jens Persson wrote:
>>>>
>>>>> I'll try to rephrase my initial post a bit, perhaps it will make my
>>>>> point
>>>>> clearer:
>>>>>
>>>>
>>>> I got your idea. Although I don't know if it is easy to implement in
>>>> compiler/parser, I know that it is hard to find such symbols (as
>>>> replacement of parentheses) that will be easy to type on keyboard. Don't
>>>> you really propose to type unicode chars like ⊂ ? I believe no.
>>>>
>>>> <> - used for generics
>>>> {} - for code blocks
>>>> [] - for subscripts/arrays/dicts
>>>>
>>>> what I can think of is vertical bar | symbol as parentheses for tuples:
>>>>
>>>> var x = |5,5|
>>>>
>>>> func foo(tuple: |Int,Int,String|) {..}
>>>>
>>>> (|Int,Int|)->Int
>>>> (|Int,Int|)->|String, String|
>>>>
>>>> ((Int) -> Int)?  -- optional function
>>>> |(Int) -> Int|?  -- optional tuple
>>>>
>>>> I feel like such syntax for tuples more clearly separates tuple
>>>> declaration from other parts of code.
>>>> Don't know if that makes sense :-)
>>>> And not sure if we really needs one-element tuple even if we can
>>>> clearly parse it in source.
>>>>
>>>> Btw, parentheses are required for argument list in function type now,
>>>> so we can't write `Int -> Int`, but only as `(Int) -> Int`, and not `(Int
>>>> -> Int)?` but as `((Int) -> Int)?`
>>>>
>>>>
>>>>> Might it be that some of the confusion regarding the evolution
>>>>> (design/redesign) of tuples, parameter lists, etc. stems from the fact
>>>>> that
>>>>> they all use parentheses? Or put differently: Parentheses, being used
>>>>> for
>>>>> so many different (and similar) things, is perhaps blurring the "real"
&

Re: [swift-evolution] [Discussion] Parentheses

[Jens Persson via swift-evolution]

Int. (remember
>>> parens are _only_ used for grouping this way)
>>>
>>> ⊂ Int, 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, but allowing it could perhaps make the rules 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 matching, associated values and more).
>>>
>>> /Jens
>>>
>>>
>>> On Wed, Jul 6, 2016 at 8:10 PM, Vladimir.S via swift-evolution
>>> mailto:swift-evolution@swift.org>> wrote:
>>>
>>> On 06.07.2016 20:51, Joe Groff wrote:
>>>
>>>
>>> On Jul 6, 2016, at 7:47 AM, Vladimir.S via swift-evolution
>>> mailto: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 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 / reality *:
>>> Complicated (exceptions to) rules.
>>>
>>> (* Inevitably not taking everything in to account.)
>>>
>>> Has there been any recent attempts to outline a more or
>>> less complete
>>> redesign for these things, returning to step 1 so to
>>> speak,
>>> but taking into
>>> account what has now been learned?
>>>
>>>
>>> As a side note (and supposedly trivial to most but me):
>>>
>>> Parentheses (parenthesized expressions in the grammar?)
>>> are
>>> used for all of
>>> these parts of the language, and they probably should be,
>>> but perhaps the
>>> similarities and differences between the language
>>> constructs can be made
>>> clearer to see by pretending that argument and parameter
>>> lists are written
>>> with eg ≪≫ and tuples with eg ⊂⊃, etc.?
>>>
>>> For example, I think most people agree that we should be
>>> able to use
>>> "sloppy/forgiving" parenthetical grouping in code such
>>> as:
>>> ((1 + (2 * 3)) * (x + (-5))) - y
>>> This is fine and can be used to express meaning for the
>>> person
>>> reading/writing, even though it means that some of the
>>> parens can become
>>> superfluous to a machine interpretation.
>>>
>>> AFAICS this need not have anything to do with tuples
>>> and/or
>>> parameter
>>> lists, but the fact that Swift is treating eg:
>>> func foo(x: Int) { print(x) }
>>> as
>>> func foo(x: Int) { print(x) }
>>> and
>>> ((Int, Int))
>>> as
>>> (Int, Int)
>>>
>>>
>>> If SE-0110 will be accepted, ((Int, Int)) will mean "1 tuple
>>> with Int,Int fields" and (Int, Int) will mean only "list of
>>> two
>>> Ints in parameters"
>>>
>>>
>>> ((Int, Int)) would still be equivalent to (Int, Int). SE-0110
>>> only
>>> concerns parameter lists in function types.
>>>
>>>
>>> Yes, I'm talking about parameter list in function. Perhaps I'm
>>> missin

Re: [swift-evolution] [Discussion] Parentheses

[Jens Persson via swift-evolution]

As previously mentioned, I was talking about using those symbols only as a
thinking-tool to possibly simplify language design, making the "real"
differences and similarities easier to see while thinking about the design.
The final syntax could perhaps still use normal parentheses for all
these parts of the language. Please reread my previous two posts for more
details.
/Jens


On Thursday, July 7, 2016, Vladimir.S  wrote:

> On 06.07.2016 22:37, Jens Persson wrote:
>
>> I'll try to rephrase my initial post a bit, perhaps it will make my point
>> clearer:
>>
>
> I got your idea. Although I don't know if it is easy to implement in
> compiler/parser, I know that it is hard to find such symbols (as
> replacement of parentheses) that will be easy to type on keyboard. Don't
> you really propose to type unicode chars like ⊂ ? I believe no.
>
> <> - used for generics
> {} - for code blocks
> [] - for subscripts/arrays/dicts
>
> what I can think of is vertical bar | symbol as parentheses for tuples:
>
> var x = |5,5|
>
> func foo(tuple: |Int,Int,String|) {..}
>
> (|Int,Int|)->Int
> (|Int,Int|)->|String, String|
>
> ((Int) -> Int)?  -- optional function
> |(Int) -> Int|?  -- optional tuple
>
> I feel like such syntax for tuples more clearly separates tuple
> declaration from other parts of code.
> Don't know if that makes sense :-)
> And not sure if we really needs one-element tuple even if we can clearly
> parse it in source.
>
> Btw, parentheses are required for argument list in function type now, so
> we can't write `Int -> Int`, but only as `(Int) -> Int`, and not `(Int ->
> Int)?` but as `((Int) -> Int)?`
>
>
>> Might it be that some of the confusion regarding the evolution
>> (design/redesign) of tuples, parameter lists, etc. stems from the fact
>> that
>> they all use parentheses? Or put differently: Parentheses, being used for
>> so many different (and similar) things, is perhaps blurring the "real"
>> (possibly simpler) similarities and differences.
>>
>> I'm not saying they should not all use parentheses in the final design,
>> I'm
>> only saying that perhaps it is making it harder to think clearly about
>> these things (while designing  the language).
>>
>> Let's say we carry out a thought-experiment in which we assume
>> that argument and parameter lists use eg ≪≫ and tuples use eg ⊂⊃, and
>> normal parentheses are _only_ used for grouping and controlling priority
>> in
>> eg mathematical expressions, but not when creating tuples, parameter
>> lists,
>> pattern matching and closure types.
>>
>> Using this notation (which is just a thinking-tool, not meant as a final
>> syntax), and reimagining these things from scratch, we could for example
>> try and see what happens if we assume that these are three _different_
>> types:
>> Int
>> ⊂Int ⊃
>> ⊂⊂ Int ⊃⊃
>> and also, for example, that it is ok to have single element tuples with an
>> element label.
>> And:
>>
>> ((-1) * ((x + y) + (3 * y))) // Still OK. Redundant parens are treated as
>> usual / as before.
>>
>> ⊂ String, Int ⊃ // Two element tuple type whose elements are a String and
>> an Int.
>>
>> ⊂ Int ⊃ // Single element Tuple type.
>>
>> ⊂⊂ Int ⊃⊃ // Single element Tuple type whose only element is another
>> single
>> element tuple type whose only element is an Int.
>>
>> ≪ Int ≫ -> Int // Function type from Int to Int.
>>
>> Perhaps the ≪≫ would prove to be unnecessary, so:
>>
>> Int -> Int // Function type from Int to Int.
>> (Int -> Int)? // Optional function type from Int to Int.
>> Int -> Int? // Optional function type from Int to Int. (remember
>> parens are _only_ used for grouping this way)
>>
>> ⊂ Int, 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, but allowing it could perhaps make the rules 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 matching, associated values and more).
>>
>> /Jens
>>
>>
>> On Wed, Jul 6, 2016 at 8:10 PM, Vladimir.S via swift-evolution
>> mailto:swift-evolution@swift.org>> 

Re: [swift-evolution] [Discussion] Parentheses

[Jens Persson via swift-evolution]

I'll try to rephrase my initial post a bit, perhaps it will make my point
clearer:

Might it be that some of the confusion regarding the evolution
(design/redesign) of tuples, parameter lists, etc. stems from the fact that
they all use parentheses? Or put differently: Parentheses, being used for
so many different (and similar) things, is perhaps blurring the "real"
(possibly simpler) similarities and differences.

I'm not saying they should not all use parentheses in the final design, I'm
only saying that perhaps it is making it harder to think clearly about
these things (while designing  the language).

Let's say we carry out a thought-experiment in which we assume that argument
and parameter lists use eg ≪≫ and tuples use eg ⊂⊃, and normal parentheses
are _only_ used for grouping and controlling priority in eg mathematical
expressions, but not when creating tuples, parameter lists, pattern
matching and closure types.

Using this notation (which is just a thinking-tool, not meant as a final
syntax), and reimagining these things from scratch, we could for example
try and see what happens if we assume that these are three _different_
types:
Int
⊂Int ⊃
⊂⊂ Int ⊃⊃
and also, for example, that it is ok to have single element tuples with an
element label.
And:

((-1) * ((x + y) + (3 * y))) // Still OK. Redundant parens are treated as
usual / as before.

⊂ String, Int ⊃ // Two element tuple type whose elements are a String and
an Int.

⊂ Int ⊃ // Single element Tuple type.

⊂⊂ Int ⊃⊃ // Single element Tuple type whose only element is another single
element tuple type whose only element is an Int.

≪ Int ≫ -> Int // Function type from Int to Int.

Perhaps the ≪≫ would prove to be unnecessary, so:

Int -> Int // Function type from Int to Int.
(Int -> Int)? // Optional function type from Int to Int.
Int -> Int? // Optional function type from Int to Int. (remember
parens are _only_ used for grouping this way)

⊂ Int, 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, but allowing it could perhaps make the rules 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 matching, associated values and more).

/Jens


On Wed, Jul 6, 2016 at 8:10 PM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> On 06.07.2016 20:51, Joe Groff wrote:
>
>>
>> On Jul 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
>>>> 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 / reality *:
>>>> Complicated (exceptions to) rules.
>>>>
>>>> (* Inevitably not taking everything in to account.)
>>>>
>>>> Has there been any recent attempts to outline a more or less complete
>>>> redesign for these things, returning to step 1 so to speak, but taking
>>>> into
>>>> account what has now been learned?
>>>>
>>>>
>>>> As a side note (and supposedly trivial to most but me):
>>>>
>>>> Parentheses (parenthesized expressions in the grammar?) are used for
>>>> all of
>>>> these parts of the language, and they probably should be, but perhaps
>>>> the
>>>> similarities and differences between the language constructs can be made
>>>> clearer to see by pretending that argument and parameter lists are
>>>> written
>>>> with eg ≪≫ and tuples with eg ⊂⊃, etc.?
>>>>
>>>> For example, I think most people agree that we should be able to use
>>>> "sloppy/forgiving" parenthetical grouping in code such as:
>>>> ((1 + (2 * 3)) * (x + (-5))) - y
>>>> This is fine and can be used to express meaning for the person
>>>> reading/writing, even though it means that some of the parens can become
>>>> superfluous to a machine interpretation.
>>>>
>>>> AFAICS this need not have anything to do with tuple

Re: [swift-evolution] [Discussion] Parentheses

[Jens Persson via swift-evolution]

Ah, thanks Anton!
But wouldn't/couldn't things be different if tuples was written with eg ⊂⊃
instead of parentheses?
(let's ignore the practical implications (difficult to write etc) for the
moment)

For example, here's an optional tuple whose single element is a function:
⊂Int -> Int⊃?

and here is an optional function:
(Int -> Int)?

In this thought-experiment, parentheses are _only_ used for grouping
(setting priorities), and they are the only grouping which is
sloppy/forgiving, so this would also be an optional tuple whose single
element is a function:

⊂Int -> Int⊃))?))

But this would be an optional tuple whose single element is a single
element tuple whose single element is a function:
⊂⊂Int -> Int⊃⊃?

/Jens


On Wed, Jul 6, 2016 at 12:23 PM, Anton Zhilin 
wrote:

> > Or maybe I have just forgotten the reasons for why there can be no such
> thing as (a nested) single element tuple (type).
>
> In Swift, types have their own (built-in) operators: infix '->', postfix
> '?', postfix '!'.
> Parentheses are required for grouping (setting priorities). If we allow
> single element tuples, ambiguities arise:
>
> (Int -> Int)?  // is that an optional tuple or just optional function?
>
> By the way, in Haskell, which allows user-defined operators on types,
> there is no single element tuple for pretty much the same reason.
>



-- 
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: j...@bitcycle.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Discussion] Parentheses

[Jens Persson via swift-evolution]

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 / reality *:
Complicated (exceptions to) rules.

(* Inevitably not taking everything in to account.)

Has there been any recent attempts to outline a more or less complete
redesign for these things, returning to step 1 so to speak, but taking into
account what has now been learned?


As a side note (and supposedly trivial to most but me):

Parentheses (parenthesized expressions in the grammar?) are used for all of
these parts of the language, and they probably should be, but perhaps the
similarities and differences between the language constructs can be made
clearer to see by pretending that argument and parameter lists are written
with eg ≪≫ and tuples with eg ⊂⊃, etc.?

For example, I think most people agree that we should be able to use
"sloppy/forgiving" parenthetical grouping in code such as:
((1 + (2 * 3)) * (x + (-5))) - y
This is fine and can be used to express meaning for the person
reading/writing, even though it means that some of the parens can become
superfluous to a machine interpretation.

AFAICS this need not have anything to do with tuples and/or parameter
lists, but the fact that Swift is treating eg:
func foo(x: Int) { print(x) }
as
func foo(x: Int) { print(x) }
and
((Int, Int))
as
(Int, Int)
seems to suggest that it somehow does.

Or maybe I have just forgotten the reasons for why there can be no such
thing as (a nested) single element tuple (type).

I also can't remember what the pros & cons of disallowing labeled single
element tuples were.

Happy to be corrected and pointed to relevant reading : )

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

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

[Jens Persson via swift-evolution]

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 maximum funcs on FloatingPoint in Swift 3 shows
the expected behaviour (ie the same as fmin, fmax and IEEE-754), so what
should happen with Swift.min and Swift.max?

Fix, remove or perhaps something else?

https://bugs.swift.org/browse/SR-1011

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

Re: [swift-evolution] [Review] SE-0048: Generic Type Aliases

[Jens Persson via swift-evolution]

+1 for reasons already mentioned by others.

On Thu, Mar 24, 2016 at 5:54 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0048 "Generic Type Aliases" begins now and runs through
> March 29, 2016. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.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. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
>
> Reply text
>
> Other replies
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine 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,
>
> Doug Gregor
>
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: j...@bitcycle.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jens Persson via swift-evolution]

Thanks!
(As a side note related to overflow, I filed
https://bugs.swift.org/browse/SR-297 demonstrating that a
T : UnsignedIntegerType can be set to eg literal -1 without trapping the
overflow.)

On Mon, Dec 21, 2015 at 7:22 PM, Joe Groff  wrote:

>
> > On Dec 21, 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 reasonable to expect a compile time error rather than the current
> runtime error:
> >
> > import simd
> > let a: float4 = [1, 2, 3]
> > print(a)
> >
> > The SIMD float4 type conforms to ArrayLiteralConvertible, and the
> required initializer has a check that makes sure the array literal has 4
> elements.
> > The check can only be performed at runtime even though the number of
> elements of that array literal is (presumably) statically knowable, as is
> the number it is checked against (i.e. it probably ends up being an integer
> literal 4 somewhere (although I haven't actually checked the code)).
> >
> > I assume that there are good reasons for why this is currently a runtime
> check, but I'd like to know what these reasons are, i.e. why isn't there
> something like C++'s static_assert?
> >
> > Any pointers to previous discussions or information about how Swift
> relates to this and similar topics (static computation / constexpr, macro
> system) would be highly appreciated.
>
> We haven't designed any facilities for any of this yet, or really had
> serious discussions about them that I know of. They're definitely
> interesting directions for the future. There is some infrastructure for
> limited compile-time evaluation and diagnostics based on SIL; for instance,
> we produce diagnostics when literal integer expressions overflow their
> target type, as in `let x: Int8 = 128`, by doing constant-folding of
> `@_transparent` functions. There's a more generalized compile-time
> reporting mechanism we prototyped, but I don't think we currently take
> advantage of it; grep around for `staticReport`. `staticReport` in
> @_transparent function together could approximate static_assert in cases
> the compiler knows how to constant-fold.
>
> -Joe
>
>


-- 
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: j...@bitcycle.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Compile time assertion / checking?

[Jens Persson via swift-evolution]

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 reasonable to expect a compile time error rather than the current
runtime error:

import simd
let a: float4 = [1, 2, 3]
print(a)

The SIMD float4 type conforms to ArrayLiteralConvertible, and the required
initializer has a check that makes sure the array literal has 4 elements.
The check can only be performed at runtime even though the number of
elements of that array literal is (presumably) statically knowable, as is
the number it is checked against (i.e. it probably ends up being an integer
literal 4 somewhere (although I haven't actually checked the code)).

I assume that there are good reasons for why this is currently a runtime
check, but I'd like to know what these reasons are, i.e. why isn't there
something like C++'s static_assert?

Any pointers to previous discussions or information about how Swift relates
to this and similar topics (static computation / constexpr, macro system)
would be highly appreciated.

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

Re: [swift-evolution] [Proposal] function "return" optional keyword.

[Jens Persson via swift-evolution]

+1

On Sat, Dec 19, 2015 at 2:30 PM, Craig Cruden via swift-evolution <
swift-evolution@swift.org> wrote:

>
> When writing short functional code in a function it would be nice if the
> return keyword were an optional keyword.
>
> Just return the last evaluated expression.
>
>
> i.e.
>
> func flipFunc(arg1: T, arg2: U) -> (U, T) {
> (arg2, arg1)
> }
>
>
> The keyword return would still be there for breaking out of a function.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: j...@bitcycle.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] Require self for accessing instance members

[Jens Persson via swift-evolution]

Yes, to call the standalone foo, you'd call it on its module name:
TheModuleOfFoo.foo()

On Sat, Dec 19, 2015 at 6:52 AM, Kenny Leung via swift-evolution <
swift-evolution@swift.org> wrote:

> >   * What is your evaluation of the proposal?
>
> +1 for it.
>
> >   * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
> Yes. I feel it makes things more correct.
>
> >   * Does this proposal fit well with the feel and direction of Swift?
>
> Yes. One of Swift’s goals is to be clear in reading, and this makes it it
> readily explicit when an instance property or function is being referred to
> when reading over code.
>
> >   * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> I prefer a shorter syntax, like Ruby’s @blah. It will serve the same
> purpose, and save some space and typing. In fact, I would prefer to have
> all scopes of variables decorated so you could tell them all at a glance:
> - local variables have no decoration
> - instance properties with @
> - arguments with $
> - statics, globals, etc…
> - types that I have to worry about mutating because someone else might
> have a reference to it vs. ones that I don’t have to worry about. (I used
> to think this was structs vs classes, but after being on this list I’m not
> so sure…)
>
> >   * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> I have read about half of the posts on this.
>
> 
>
> Considering this makes me think - if self were not required:
>
> you have a standalone function foo()
>
> you also have an instance method foo()
>
> If you have another instance method
>
> func bar() {
> //Could you ever call the standalone function foo?
> foo()
> }
>
>
> -Kenny
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: j...@bitcycle.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

[Jens Persson via swift-evolution]

>
> strong +1 from me.  @warn_unused_result is almost always the right answer
> in the standard library, and the few cases where it isn’t are very easy to
> notice (when the call has side-effects and the return value is incidental).
>
> -Dave
>

I'm also in favour of this proposal.

Some days ago, in the swift-dev list (
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000385.html
) I was advised by Chris Lattner to bring a related issue into this
discussion:

It's about the lack of a warning for simple statements that are unused and
thus meaningless (so most probably unintentional). To demonstrate what I
mean, here's a short example that currently compiles without any warnings:

func thisFuncHasNoWarnings(a: Int) {
a
"b"
"c" as Character
1.0
[2.0, 3.0]
["four", 5, 6.7] as [Any]
"Is this"; a; "problem?"
}

I think it might be reasonable to expect a warning on every single line of
that function, no?
/Jens
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution