Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Chris Lattner via swift-evolution]

On Oct 5, 2016, at 3:57 PM, Brent Royal-Gordon  wrote:
>> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution 
>>  wrote:
>> I hadn't thought about a unified overlay for POSIX. I think the simplified 
>> import alone has benefit to warrant its own evolution proposal. Would it be 
>> possible to have a separate discussion for the POSIX overlay idea? Or is 
>> there a reason that I'm missing that prevents the import from being viable 
>> on its own? (Apologies in advance if there's an obvious answer to this 
>> question!)
> 
> I've heard the argument before that we should do a full overlay, but I think 
> this is becoming a case of the perfect being the enemy of the good. Having 
> some sort of "just import whatever the system libc is called" module would be 
> a significant improvement in practice over the state of the art, even if we 
> don't do any other adaptation.

I’ve come around to agree with this position.  I think it makes sense to have a 
cross platform “libc” which is an alias for darwin, glibc, or whatever, and 
just leave it at that.

Other proposals for a “POSIX” module have gotten bogged down because inevitably 
the idea comes up to make the resultant API nicer in various ways: rename 
creat, handle errno more nicely, make use of multiple return values, … etc.  
The problem with this approach is that we don’t *want* people using these layer 
of APIs, we want higher level Foundation-like APIs to be used.

That’s why I think the best way to split the difference is to do as you 
suggest.  This allows the implementation of Foundation (and similar level of 
APIs) to be nicer, but not get bogged down trying to figure out how to clean up 
POSIX.

> Here's what I would suggest. We have a convention for exposing "raw" imports 
> of C libraries: you call them `C\(libraryName)`. So I would suggest we 
> introduce a `CLibc` module which provides a raw import of the system's libc. 
> If we later decide to do a full-featured overlay, that's great—we can call it 
> `Libc`. But `CLibc` by itself would be an improvement over the status quo and 
> a step in the right direction.

I think we should formally decide that a “nice” wrapper for libc is a non-goal. 
 There is too much that doesn’t make sense to wrap at this level - the only 
Swift code that should be using this is the implementation of higher level API, 
and such extremely narrow cases that we can live with them having to handle the 
problems of dealing with the raw APIs directly.

-Chris


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

Re: [swift-evolution] [Pitch] inout with capture variable

[Cao Jiannan via swift-evolution]

I just want to demo how the inout capture works.
the demo code just want to capture value avoiding capture self.


> > On Oct 5, 2016, at 10:07 PM, Cao 
> > Jiannanwrote:
> > so if developer want to capture an variable inference, must declare a new 
> > variable.
> I don’t follow what you mean here.
> 
> > 
> > classA {
> > varvalue = 1
> > 
> > functest() ->() ->Int{
> > varcapturedValue =self.value
> > leteditInfo = { () ->Intin
> > capturedValue += 1
> > returncapturedValue
> > }
> > returneditInfo
> > }
> > }
> > 
> > leta =A()
> > 
> > leteditInfo =a.test()
> > print(editInfo()) // 2
> > print(a.value) // 1
> > 
> > print(editInfo()) // 3
> > 
> > print(a.value) // 1
> > 
> > what about:
> > 
> > classA {
> > varvalue = 1
> > 
> > functest() ->() ->Int{
> > leteditInfo = { [inout value] () ->Intin
> > capturedValue += 1
> > returncapturedValue
> > }
> > returneditInfo
> > }
> > }
> > 
> > leta =A()
> > 
> > leteditInfo =a.test()
> > print(editInfo()) // 2
> > print(a.value) // 2
> > 
> > 
> > print(editInfo()) // 3
> > 
> > print(a.value) // 3
> > 
> > 
> > 
> > 
> I’m not quite sure what you’re getting at, but this prints what you’re 
> expecting in the output you have in the comments:
> 
> class A {
> var value = 1
> 
> func test() ->() ->Int {
> let editInfo = { () ->Int in
> self.value += 1
> return self.value
> }
> return editInfo
> }
> }
> 
> let a = A()
> 
> let editInfo = a.test()
> print(editInfo()) // 2
> print(a.value) // 2
> print(editInfo()) // 3
> print(a.value) // 3
> 
> 
> Mark
> 
> > 
> > >>On Oct 5, 2016, at 9:06 PM, Cao Jiannan via 
> > >>swift-evolutionwrote:
> > >>
> > >>for example:
> > >>
> > >>var a = 1
> > >>
> > >>let block = { [inout a] in
> > >>a += 1
> > >>}
> > >>
> > >>block()
> > >>block()
> > >>
> > >>print(a) // 3
> > >This is already how captures work by default in closures and nested 
> > >functions in Swift:
> > >
> > >var a = 1
> > >
> > >let block = { a += 1 }
> > >
> > >block()
> > >block()
> > >
> > >print(a) // prints 3
> > >
> > >
> > >If you want to capture something immutably you can put it in the capture 
> > >list:
> > >
> > >var a = 1
> > >let block = { [a] in a += 1 } // error: left side of mutating operator 
> > >isn't mutable: 'a' is a 'let' constant
> > >
> > >Mark
> > >
> > >>
> > >>
> > >>___
> > >>swift-evolution mailing list
> > >>swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > >>https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > >
> > >
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] inout with capture variable

[Mark Lacey via swift-evolution]

> On Oct 5, 2016, at 10:07 PM, Cao Jiannan  wrote:
> 
> so if developer want to capture an variable inference, must declare a new 
> variable.

I don’t follow what you mean here.

> 
> class A {
> var value = 1
> 
> func test() -> () -> Int {
> var capturedValue = self.value
> let editInfo = { () -> Int in 
> capturedValue += 1
> return capturedValue
> }
> return editInfo
> }
> }
> 
> let a = A()
> 
> let editInfo = a.test()
> print(editInfo()) // 2
> print(a.value) // 1
> print(editInfo()) // 3
> print(a.value) // 1
> 
> what about:
> 
> class A {
> var value = 1
> 
> func test() -> () -> Int {
> let editInfo = { [inout value] () -> Int in 
> capturedValue += 1
> return capturedValue
> }
> return editInfo
> }
> }
> 
> let a = A()
> 
> let editInfo = a.test()
> print(editInfo()) // 2
> print(a.value) // 2
> print(editInfo()) // 3
> print(a.value) // 3

I’m not quite sure what you’re getting at, but this prints what you’re 
expecting in the output you have in the comments:

class A {
var value = 1

func test() -> () -> Int {
let editInfo = { () -> Int in 
self.value += 1
return self.value
}
return editInfo
}
}

let a = A()

let editInfo = a.test()
print(editInfo()) // 2
print(a.value) // 2
print(editInfo()) // 3
print(a.value) // 3


Mark

> 
> > > On Oct 5, 2016, at 9:06 PM, Cao Jiannan via 
> > > swift-evolution > > >wrote:
> > > 
> > > for example:
> > > 
> > > var a = 1
> > > 
> > > let block = { [inout a] in
> > > a += 1
> > > }
> > > 
> > > block()
> > > block()
> > > 
> > > print(a) // 3
> > This is already how captures work by default in closures and nested 
> > functions in Swift:
> > 
> > var a = 1
> > 
> > let block = { a += 1 }
> > 
> > block()
> > block()
> > 
> > print(a) // prints 3
> > 
> > 
> > If you want to capture something immutably you can put it in the capture 
> > list:
> > 
> > var a = 1
> > let block = { [a] in a += 1 } // error: left side of mutating operator 
> > isn't mutable: 'a' is a 'let' constant
> > 
> > Mark
> > 
> > > 
> > > 
> > > ___
> > > 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] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Brent Royal-Gordon via swift-evolution]

> On Oct 5, 2016, at 8:55 PM, Xiaodi Wu  wrote:
> 
> See, I'd assumed that the "unified" Darwin/Glibc would simply be what you 
> call Platform. And if we're going to have that overlay, what's the point of 
> also renaming Darwin/Glibc to CPlatform, given that it's going to be 
> different between platforms, and given that what's not going to be in the 
> Platform overlay is much more likely to be the divergent bits?

The difference I imagine between `Platform` and `CPlatform` is that `Platform` 
would do things like:

* Convert `errno`-setting functions to throwing functions.
* Convert many returns by pointer parameter into tuple returns.
* Encapsulate certain structures, like `FILE` and `sockaddr`, which are really 
awkward to use in Swift.
* Organize free-floating constants into enums.
* Possibly move some operations from free functions to methods.

Whereas `CPlatform` would be basically a straight import of the C libraries, 
warts and all.

I don't actually imagine that `Platform` would do much platform abstraction 
except in trivial cases, like the ones currently in 
stdlib/public/Platform/Misc.c.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] inout with capture variable

[Cao Jiannan via swift-evolution]

so if developer want to capture an variable inference, must declare a new 
variable.

class A {
var value = 1

func test() -> () -> Int {
var capturedValue = self.value
let editInfo = { () -> Int in 
capturedValue += 1
return capturedValue
}
return editInfo
}
}

let a = A()

let editInfo = a.test()
print(editInfo()) // 2
print(a.value) // 1
print(editInfo()) // 3
print(a.value) // 1

what about:

class A {
var value = 1

func test() -> () -> Int {
let editInfo = { [inout value] () -> Int in 
capturedValue += 1
return capturedValue
}
return editInfo
}
}

let a = A()

let editInfo = a.test()
print(editInfo()) // 2
print(a.value) // 2
print(editInfo()) // 3
print(a.value) // 3

> > On Oct 5, 2016, at 9:06 PM, Cao Jiannan via 
> > swift-evolutionwrote:
> > 
> > for example:
> > 
> > var a = 1
> > 
> > let block = { [inout a] in
> > a += 1
> > }
> > 
> > block()
> > block()
> > 
> > print(a) // 3
> This is already how captures work by default in closures and nested functions 
> in Swift:
> 
> var a = 1
> 
> let block = { a += 1 }
> 
> block()
> block()
> 
> print(a) // prints 3
> 
> 
> If you want to capture something immutably you can put it in the capture list:
> 
> var a = 1
> let block = { [a] in a += 1 } // error: left side of mutating operator isn't 
> mutable: 'a' is a 'let' constant
> 
> Mark
> 
> > 
> > 
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] inout with capture variable

[Mark Lacey via swift-evolution]

> On Oct 5, 2016, at 9:06 PM, Cao Jiannan via swift-evolution 
>  wrote:
> 
> for example:
> 
> var a = 1
> 
> let block = { [inout a] in
>   a += 1
> }
> 
> block()
> block()
> 
> print(a) // 3

This is already how captures work by default in closures and nested functions 
in Swift:

var a = 1

let block = { a += 1 }

block()
block()

print(a) // prints 3


If you want to capture something immutably you can put it in the capture list:

var a = 1
let block = { [a] in a += 1 } // error: left side of mutating operator isn't 
mutable: 'a' is a 'let' constant

Mark

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

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

Re: [swift-evolution] [Pitch] inout with capture variable

[Daniel Resnick via swift-evolution]

You can currently achieve the same result if you remove `[inout a]` since
`var`s are captured by reference.

On Wed, Oct 5, 2016 at 9:06 PM, Cao Jiannan via swift-evolution <
swift-evolution@swift.org> wrote:

> for example:
>
> var a = 1
>
> let block = { [inout a] in
> a += 1
> }
>
> block()
> block()
>
> print(a) // 3
>
>
> ___
> 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] [Pitch] inout with capture variable

[Cao Jiannan via swift-evolution]

for example:

var a = 1

let block = { [inout a] in
a += 1
}

block()
block()

print(a) // 3


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

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Xiaodi Wu via swift-evolution]

On Wed, Oct 5, 2016 at 10:47 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Oct 5, 2016, at 7:08 PM, Greg Parker  wrote:
> >
> >> Now, as for naming: I like using the leading "C" convention ("CLibc")
> because it leaves us room for introducing an overlaid version of the module
> in the future without breaking source compatibility. Because of this, I
> wouldn't want to name the module just `C`, because it wouldn't leave room
> for a Swifty version later.
> >
> > I don't think separating the raw C library translation from the pretty
> Swift wrapper works, at least not for everybody. The problem is that the
> raw translation is going to have functions that the pretty wrapper does
> not. (Perhaps the pretty wrapper is new and incomplete. Perhaps an OS has
> added functions and the pretty wrapper has not caught up yet.)  If you try
> to import both then you end up with the same problems of name collisions
> today and source incompatibility in the future when the pretty wrapper
> grows.
>
> I didn't mean that you could import both—merely that, if you used CLibc
> (or CPlatform) today, the introduction of the pretty Libc or Platform in a
> future version of Swift wouldn't affect your existing code.
>
> As for handing unsupported features, I'd like you to be able to say
> something like (using a version of today's syntax):
>
> import Platform
> import func CPlatform.newfunc(_:_:)
>
> Which would hopefully mean that, if a future version of Libc added
> newfunc(_:_:), the CLibc version—which is the one we explicitly
> requested—would shadow it. (Perhaps when you rebuilt against the newer
> version of Libc, you'd get a shadowing warning that would hint to you that
> you don't need to pull that function in from CLibc anymore.)
>

See, I'd assumed that the "unified" Darwin/Glibc would simply be what you
call Platform. And if we're going to have that overlay, what's the point of
also renaming Darwin/Glibc to CPlatform, given that it's going to be
different between platforms, and given that what's not going to be in the
Platform overlay is much more likely to be the divergent bits?


> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Brent Royal-Gordon via swift-evolution]

> On Oct 5, 2016, at 7:08 PM, Greg Parker  wrote:
> 
>> Now, as for naming: I like using the leading "C" convention ("CLibc") 
>> because it leaves us room for introducing an overlaid version of the module 
>> in the future without breaking source compatibility. Because of this, I 
>> wouldn't want to name the module just `C`, because it wouldn't leave room 
>> for a Swifty version later.
> 
> I don't think separating the raw C library translation from the pretty Swift 
> wrapper works, at least not for everybody. The problem is that the raw 
> translation is going to have functions that the pretty wrapper does not. 
> (Perhaps the pretty wrapper is new and incomplete. Perhaps an OS has added 
> functions and the pretty wrapper has not caught up yet.)  If you try to 
> import both then you end up with the same problems of name collisions today 
> and source incompatibility in the future when the pretty wrapper grows.

I didn't mean that you could import both—merely that, if you used CLibc (or 
CPlatform) today, the introduction of the pretty Libc or Platform in a future 
version of Swift wouldn't affect your existing code.

As for handing unsupported features, I'd like you to be able to say something 
like (using a version of today's syntax):

import Platform
import func CPlatform.newfunc(_:_:)

Which would hopefully mean that, if a future version of Libc added 
newfunc(_:_:), the CLibc version—which is the one we explicitly requested—would 
shadow it. (Perhaps when you rebuilt against the newer version of Libc, you'd 
get a shadowing warning that would hint to you that you don't need to pull that 
function in from CLibc anymore.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Greg Parker via swift-evolution]

> On Oct 5, 2016, at 6:38 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Now, as for naming: I like using the leading "C" convention ("CLibc") because 
> it leaves us room for introducing an overlaid version of the module in the 
> future without breaking source compatibility. Because of this, I wouldn't 
> want to name the module just `C`, because it wouldn't leave room for a Swifty 
> version later.

I don't think separating the raw C library translation from the pretty Swift 
wrapper works, at least not for everybody. The problem is that the raw 
translation is going to have functions that the pretty wrapper does not. 
(Perhaps the pretty wrapper is new and incomplete. Perhaps an OS has added 
functions and the pretty wrapper has not caught up yet.)  If you try to import 
both then you end up with the same problems of name collisions today and source 
incompatibility in the future when the pretty wrapper grows.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Brent Royal-Gordon via swift-evolution]

> On Oct 5, 2016, at 4:14 PM, David Waite  wrote:
> 
> I certainly wonder what people specifically want to bring the C standard 
> library or POSIX libraries in for - is it compatibility with third party 
> libraries? Functionality missing in Foundation?

I see a number of reasons:

1. Accessing functionality not present in Foundation.

a. Using subsystems completely omitted in Foundation (e.g. C 
strings).

b. Taking finer-grained control of features than Foundation 
permits.

c. Using platform-specific features you can't expect Foundation 
to support (e.g. random ioctls).

2. Avoiding overhead introduced by Foundation abstractions.

3. Porting code currently written with libc.

4. Interoperating with code that uses libc data types (e.g. an embedded 
HTTP server written in C which uses C-level sockets).

5. Implementing Foundation itself, or implementing systems that are 
lower level than Foundation.

The bottom line is, there are a lot of reasons why you might want to work with 
a lower-level API instead of a higher-level one. Foundation is great, but it's 
not practical to say that if Foundation isn't doing the job for you, the answer 
is to improve Foundation—especially since Corelibs Foundation is trying to 
match a proprietary Apple Foundation which is entirely outside community 
control.

A CLibc module (or whatever you want to call it) is a simple and practical 
solution that doesn't preclude future improvements in Foundation or in 
presenting libc in a more Swifty form in the future. In fact, I believe 
Foundation and Swift-style libc modules would end up using CLibc.

Now, as for naming: I like using the leading "C" convention because it leaves 
us room for introducing an overlaid version of the module in the future without 
breaking source compatibility. Because of this, I wouldn't want to name the 
module just `C`, because it wouldn't leave room for a Swifty version later.

If we don't want to use words like `Libc` or `POSIX` because the module will 
import nonstandard APIs too, then I would suggest using `Platform`, or more 
specifically `CPlatform` for the non-overlaid version. This would make it clear 
that you're importing platform-provided capabilities, not something provided by 
Swift. It also implies that some APIs might be platform-specific, so you have 
at least a hint that you may be below the layers where libraries will abstract 
away platform differences for you. And the word `Platform` is vague about 
layering, whereas a name like `OS` might sometimes be inaccurate ("but this 
call isn't in the OS, it's in the C library!").

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

[Erica Sadun via swift-evolution]

> On Oct 5, 2016, at 8:29 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 4 Oct 2016, at 16:30, Tim Vermeulen via swift-evolution 
>> > wrote:
>> 
>> I think I agree with you. The postfix `!` operator is always shorthand for 
>> `fatalError()` (and some more syntax), and it would fit nicely with 
>> `default: fatalError()`.
>> 
>> The Swift usage of `?` is indeed different than `default: break` would do, 
>> so `switch?` wouldn’t convey the right message. I hadn’t given it enough 
>> thought. I still think a shorthand for `default: break` would be _nice_, but 
>> it surely shouldn’t change the `?` consistency, it also shouldn’t replace 
>> the current `switch` (as exhaustiveness is very useful) and it’s probably 
>> not worth introducing new syntax for.
>> 
>>> On 4 Oct 2016, at 16:36, Xiaodi Wu >> > wrote:
>>> 
>>> There is a plausible argument for `switch!`, because it is not possible for 
>>> the compiler to prove exhaustiveness in all circumstances where you might 
>>> know it to be the case.
>>> 
>>> However, I'd be very against `switch?`: it undermines the exhaustiveness 
>>> guarantee of the switch statement and is wholly inconsistent with Swift 
>>> usage of `?`, which indicates the possibility of an Optional. We simply 
>>> don't need a new spelling for `default: break`.
> 
> I agree with Tim; I'm a +1 for switch! for a convenient means of erroring 
> out, but I think switch? is a bit too different from normal usage of the 
> question-mark.
> 
> One other alternative might be if there could be some kind of switch else 
> syntax, kind of like a guard statement, allowing options on what to do? Only 
> problem is how best to structure it, as the use of break might confusing as 
> to its scope, like so:
> 
>   switch(foo) else break { // Break from the switch, or the enclosing 
> block?
> 
> So I'm not 100% on that. But it would mean that switch! would be a shorthand 
> for switch else fatalError().

I will courteously jump in with a -1 for both switch! and switch?. I get how 
pretty they are at first glance:  they have symmetry with existing constructs. 
However:

* I doubt they'll be used much and I don't think something should be added to 
the language without measurable and consequential benefits.

* I don't think 

`default: fatalError() // this should never happen, cases are exhaustive` 

is a burden to type, in fact, I like how self-documenting it is, even if the 
compiler sometimes guesses wrong -- in fact, I think the compiler *should* 
guess wrong, especially on especially oddball case sets like `(.min ..< 0)` and 
`(0 ... .max)`, let alone cases where you only want the even values within 
those ranges.

* I do think that visually scanning for switch variants places a burden on code 
readability. Unlike try? and try!, the switch!? statement will likely be lines 
and lines away from where it impacts code. The place that best means "this 
should never happen, cases are exhaustive" is the default case.

-- E

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

[swift-evolution] Currying/Partial Application

[Jonathan Hull via swift-evolution]

Erica’s thread on currying made me remember a (very) early discussion on the 
topic where currying was being removed temporarily in hopes that partial 
application could be added back in later with better syntax.

I would really like to be able to do the following:

let partial = myFunc(a: 5, b: _, c: 7)
let ans = partial(b: 6)

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

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Xiaodi Wu via swift-evolution]

On Wed, Oct 5, 2016 at 6:14 PM, David Waite via swift-evolution <
swift-evolution@swift.org> wrote:

> If we are pulling in functions/structures not defined by the C standard
> library or by POSIX, I’d be reluctant to support a standard name. It would
> be troublesome if someone thought that they were cross-platform but turned
> out to use strfry() heavily
>
> I certainly wonder what people specifically want to bring the C standard
> library or POSIX libraries in for - is it compatibility with third party
> libraries? Functionality missing in Foundation?
>

To throw one use case out there, it's used extensively in
corelibs-foundation itself.


> -DW
>
> > On Oct 5, 2016, at 4:57 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> I hadn't thought about a unified overlay for POSIX. I think the
> simplified import alone has benefit to warrant its own evolution proposal.
> Would it be possible to have a separate discussion for the POSIX overlay
> idea? Or is there a reason that I'm missing that prevents the import from
> being viable on its own? (Apologies in advance if there's an obvious answer
> to this question!)
> >
> > I've heard the argument before that we should do a full overlay, but I
> think this is becoming a case of the perfect being the enemy of the good.
> Having some sort of "just import whatever the system libc is called" module
> would be a significant improvement in practice over the state of the art,
> even if we don't do any other adaptation.
> >
> > Here's what I would suggest. We have a convention for exposing "raw"
> imports of C libraries: you call them `C\(libraryName)`. So I would suggest
> we introduce a `CLibc` module which provides a raw import of the system's
> libc. If we later decide to do a full-featured overlay, that's great—we can
> call it `Libc`. But `CLibc` by itself would be an improvement over the
> status quo and a step in the right direction.
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
 


Hello Swift Community,

The review of SE-0142 "Permit where clauses to constrain associated types” ran 
from September 23…30, 2016. Feedback on this proposal was overwhelmingly 
positive. The proposal is accepted. 

- Doug

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

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[David Waite via swift-evolution]

If we are pulling in functions/structures not defined by the C standard library 
or by POSIX, I’d be reluctant to support a standard name. It would be 
troublesome if someone thought that they were cross-platform but turned out to 
use strfry() heavily

I certainly wonder what people specifically want to bring the C standard 
library or POSIX libraries in for - is it compatibility with third party 
libraries? Functionality missing in Foundation?

-DW

> On Oct 5, 2016, at 4:57 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution 
>>  wrote:
>> 
>> I hadn't thought about a unified overlay for POSIX. I think the simplified 
>> import alone has benefit to warrant its own evolution proposal. Would it be 
>> possible to have a separate discussion for the POSIX overlay idea? Or is 
>> there a reason that I'm missing that prevents the import from being viable 
>> on its own? (Apologies in advance if there's an obvious answer to this 
>> question!)
> 
> I've heard the argument before that we should do a full overlay, but I think 
> this is becoming a case of the perfect being the enemy of the good. Having 
> some sort of "just import whatever the system libc is called" module would be 
> a significant improvement in practice over the state of the art, even if we 
> don't do any other adaptation.
> 
> Here's what I would suggest. We have a convention for exposing "raw" imports 
> of C libraries: you call them `C\(libraryName)`. So I would suggest we 
> introduce a `CLibc` module which provides a raw import of the system's libc. 
> If we later decide to do a full-featured overlay, that's great—we can call it 
> `Libc`. But `CLibc` by itself would be an improvement over the status quo and 
> a step in the right direction.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] [Accepted] SE-0141: Availability by Swift version

[Douglas Gregor via swift-evolution]

Hello Swift community,

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0141-available-by-swift-version.md
 


The review of SE-0141 "Availability by Swift version” ran from September 
23...28 , 2016. Feedback on the proposal was light but entirely positive. The 
proposal is accepted.

- Doug

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

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Xiaodi Wu via swift-evolution]

On Wed, Oct 5, 2016 at 5:57 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I hadn't thought about a unified overlay for POSIX. I think the
> simplified import alone has benefit to warrant its own evolution proposal.
> Would it be possible to have a separate discussion for the POSIX overlay
> idea? Or is there a reason that I'm missing that prevents the import from
> being viable on its own? (Apologies in advance if there's an obvious answer
> to this question!)
>
> I've heard the argument before that we should do a full overlay, but I
> think this is becoming a case of the perfect being the enemy of the good.
> Having some sort of "just import whatever the system libc is called" module
> would be a significant improvement in practice over the state of the art,
> even if we don't do any other adaptation.
>
> Here's what I would suggest. We have a convention for exposing "raw"
> imports of C libraries: you call them `C\(libraryName)`. So I would suggest
> we introduce a `CLibc` module which provides a raw import of the system's
> libc. If we later decide to do a full-featured overlay, that's great—we can
> call it `Libc`. But `CLibc` by itself would be an improvement over the
> status quo and a step in the right direction.
>

I do believe that an even terser name has been suggested in the past for
libc, to avoid the repetition: just `C`.


>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Tyler Cloutier via swift-evolution]

There is also a similar intent for Zewo’s POSIX:

https://github.com/Zewo/POSIX/blob/master/Sources/POSIX

It would be great to have something included with Swift.


> On Sep 14, 2016, at 5:59 AM, Alex Blewitt via swift-evolution 
>  wrote:
> 
> Vapor's Core package expresses a target called simply 'libc':
> 
> https://github.com/vapor/core/blob/master/Sources/libc/libc.swift 
> 
> 
> As a result, their Swift files simply say "import libc"
> 
> https://github.com/vapor/core/blob/master/Sources/Core/Lock.swift 
> 
> 
> Alex
> 
>> On 13 Sep 2016, at 20:29, Brian Gesiak via swift-evolution 
>> > wrote:
>> 
>> Resurrecting this discussion since the question of "why does Android import 
>> Glibc?" came up on this swift-corelibs-foundation pull request: 
>> https://github.com/apple/swift-corelibs-foundation/pull/622#discussion_r77848100
>>  
>> 
>> 
>> I think that it is also important to ask what the real goal here is.  
>> Foundation is our cross platform compatibility layer, are there specific 
>> deficiencies in the Foundation API that cause a problem here, or is it just 
>> that not all of corelibs Foundation is “done” yet?
>> 
>> When I first proposed the idea, I simply wanted to turn these five lines:
>> 
>> #if os(Linux) || os(FreeBSD) || os(Android) || os(PS4)
>> import Glibc
>> #else
>> import Darwin
>> #endif
>> 
>> Into this one line:
>> 
>> import WhateverNameWeDecideUpon
>> 
>> After all, writing five lines of code for the import is painful, and the 
>> list of `#if os(...) || os(...) || ...` is always expanding.
>> 
>> I hadn't thought about a unified overlay for POSIX. I think the simplified 
>> import alone has benefit to warrant its own evolution proposal. Would it be 
>> possible to have a separate discussion for the POSIX overlay idea? Or is 
>> there a reason that I'm missing that prevents the import from being viable 
>> on its own? (Apologies in advance if there's an obvious answer to this 
>> question!)
>> 
>> - Brian Gesiak
>> 
>> ___
>> 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] SE-0111 and Curried argument labels: Unintended Consequences

[Douglas Gregor via swift-evolution]

> On Oct 5, 2016, at 8:15 AM, Jon Akhtar via swift-evolution 
>  wrote:
> 
> I agree this seems like a pretty serious oversight. This is very un-swifty. 
> Currying at one time was touted as a language feature, now it is more of an 
> afterthought.

I see it as a feature that has mostly been removed in Swift 3: SE-0002 

 eliminating the syntax that defined curried functions, and SE-0042 

 eliminates the production of curried functions when referring to an instance 
member.  I think that’s because, as a language feature, currying wasn’t really 
carrying it’s conceptual weight: it wasn’t being used *that* often in practice, 
but—unless you’re already familiar with currying from another language—it’s a 
fairly complicated notion to understand, and Swift didn’t ever have a complete 
implementation of currying.

- Doug

> 
> -Jon
> 
> From:  > on behalf of Erica Sadun via 
> swift-evolution >
> Reply-To: Erica Sadun >
> Date: Tuesday, October 4, 2016 at 09:21
> To: swift-evolution  >
> Subject: [swift-evolution] SE-0111 and Curried argument labels: Unintended 
> Consequences
> 
> SE-0111 established that Swift's type system would not allow function 
> argument labels to be expressed as part of a function type. As I've been 
> working with curried functions, I'm discovering an unintended consequence of 
> this proposal in that it strips curried functions of their external labels 
> and the resulting calls of their readability.
> 
> ```
> public func projected(
> function f: @escaping (CGFloat) -> CGFloat) ->
> (_ p0: CGPoint, _ p1: CGPoint) -> 
> (_ percent: CGFloat) -> CGPoint
> {
> ```
> 
> Calling the first level of currying still reads acceptably:
> 
> ```
> let projectedFunction = projected(function: fToApply)
> ```
> 
> But after that, the enforced label-less arguments mean all further semantics 
> have to stay within the name of the assigned partially applied function 
> symbol and all arguments must be supplied without meaning, which is not in 
> the spirit of API guidelines or under the umbrella of Swiftiness:
> 
> ```
> let fixedFunction = projectedFunction(p0, p1)
> let value = fixedFunction(0.2)
> ```
> 
> There's no way to give either the line segment start and end points or the 
> percent-of-progress arguments any labels.  Further, Xcode/QuickHelp does not 
> provide any support for documenting the roles of each curried return type.
> 
> Could this be addressed specifically for currying or has the boat sailed 
> forever on this topic?
> 
> -- E
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Several improvements points about extension and typealias

[Douglas Gregor via swift-evolution]

> On Oct 5, 2016, at 8:07 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> 
> 
> ~Robert Widmann
> 
> 2016/10/05 11:00、Cao, Jiannan via swift-evolution  > のメッセージ:
> 
>> 1. Allow extension specific dictionary
>> e.g.
>> extension Dictionary where Key == String, Value == String
>> or
>> extension Dictionary
>> 
> 
> This was just committed by Slava yesterday.

Right, the first extension is now accepted by the Swift compiler, which is 
*awesome*.

The second one is still ill-formed, because the grammar doesn’t permit it. If 
we want to go there, it needs a swift-evolution proposal.

- Doug


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

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

[Jon Akhtar via swift-evolution]

I agree this seems like a pretty serious oversight. This is very un-swifty. 
Currying at one time was touted as a language feature, now it is more of an 
afterthought.

-Jon

From: 
> 
on behalf of Erica Sadun via swift-evolution 
>
Reply-To: Erica Sadun >
Date: Tuesday, October 4, 2016 at 09:21
To: swift-evolution 
>
Subject: [swift-evolution] SE-0111 and Curried argument labels: Unintended 
Consequences

SE-0111 established that Swift's type system would not allow function argument 
labels to be expressed as part of a function type. As I've been working with 
curried functions, I'm discovering an unintended consequence of this proposal 
in that it strips curried functions of their external labels and the resulting 
calls of their readability.

```
public func projected(
function f: @escaping (CGFloat) -> CGFloat) ->
(_ p0: CGPoint, _ p1: CGPoint) ->
(_ percent: CGFloat) -> CGPoint
{
```

Calling the first level of currying still reads acceptably:

```
let projectedFunction = projected(function: fToApply)
```

But after that, the enforced label-less arguments mean all further semantics 
have to stay within the name of the assigned partially applied function symbol 
and all arguments must be supplied without meaning, which is not in the spirit 
of API guidelines or under the umbrella of Swiftiness:

```
let fixedFunction = projectedFunction(p0, p1)
let value = fixedFunction(0.2)
```

There's no way to give either the line segment start and end points or the 
percent-of-progress arguments any labels.  Further, Xcode/QuickHelp does not 
provide any support for documenting the roles of each curried return type.

Could this be addressed specifically for currying or has the boat sailed 
forever on this topic?

-- E

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

Re: [swift-evolution] [Pitch] Several improvements points about extension and typealias

[Robert Widmann via swift-evolution]

~Robert Widmann

2016/10/05 11:00、Cao, Jiannan via swift-evolution  
のメッセージ:

> 1. Allow extension specific dictionary
> e.g.
> extension Dictionary where Key == String, Value == String
> or
> extension Dictionary
> 

This was just committed by Slava yesterday.

> 2. Allow extending Equatable internally
> currently any type extend to Equatable should make theme public

"Hidden Conformances" are discussed in the generics manifesto.

> 
> 3. Allow internal typealias for a public type
> this internal typealias will only can be used in that package.

Interesting idea.

> 
> Thanks
> 
> ___
> 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] [Pitch] Several improvements points about extension and typealias

[Cao, Jiannan via swift-evolution]

1. Allow extension specific dictionary
e.g.
extension Dictionary where Key == String, Value == String
or
extension Dictionary

2. Allow extending Equatable internally
currently any type extend to Equatable should make theme public

3. Allow internal typealias for a public type
this internal typealias will only can be used in that package.

Thanks

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

[swift-evolution] [Question] Types of functions

[Anton Zhilin via swift-evolution]

// Swift 2.2print([Int].append.dynamicType)  //=> inout Array ->
Int -> ()print(print.dynamicType)  //=> (Array>, String,
String) -> ()
// Swift 3print(type(of: [Int].append))  //=> (inout Array) ->
(Int) -> ()print(type(of: print))  //=> ((Array, String, String))
-> ()

Question #1: Methods are still curried. If I’m not mistaken, there was an
accepted proposal that uncurries methods. Is it going to be implemented for
Swift 4 Stage 1?

Question #2: Why nested tuple in type of print? Is it just a formatter bug,
or… do functions still take tuples under the hood? If so, then perhaps,
implementation needs to be modified to actually use new model, and not just
make it look like it does.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

[Haravikk via swift-evolution]

> On 4 Oct 2016, at 16:30, Tim Vermeulen via swift-evolution 
>  wrote:
> 
> I think I agree with you. The postfix `!` operator is always shorthand for 
> `fatalError()` (and some more syntax), and it would fit nicely with `default: 
> fatalError()`.
> 
> The Swift usage of `?` is indeed different than `default: break` would do, so 
> `switch?` wouldn’t convey the right message. I hadn’t given it enough 
> thought. I still think a shorthand for `default: break` would be _nice_, but 
> it surely shouldn’t change the `?` consistency, it also shouldn’t replace the 
> current `switch` (as exhaustiveness is very useful) and it’s probably not 
> worth introducing new syntax for.
> 
>> On 4 Oct 2016, at 16:36, Xiaodi Wu > > wrote:
>> 
>> There is a plausible argument for `switch!`, because it is not possible for 
>> the compiler to prove exhaustiveness in all circumstances where you might 
>> know it to be the case.
>> 
>> However, I'd be very against `switch?`: it undermines the exhaustiveness 
>> guarantee of the switch statement and is wholly inconsistent with Swift 
>> usage of `?`, which indicates the possibility of an Optional. We simply 
>> don't need a new spelling for `default: break`.

I agree with Tim; I'm a +1 for switch! for a convenient means of erroring out, 
but I think switch? is a bit too different from normal usage of the 
question-mark.

One other alternative might be if there could be some kind of switch else 
syntax, kind of like a guard statement, allowing options on what to do? Only 
problem is how best to structure it, as the use of break might confusing as to 
its scope, like so:

switch(foo) else break { // Break from the switch, or the enclosing 
block?

So I'm not 100% on that. But it would mean that switch! would be a shorthand 
for switch else fatalError().___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution