Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Jacob Williams via swift-evolution]

Pardon my lack of knowledge in this area, but is there not also a 3rd option 
available?

(C) Split libswiftCore.dylib into two dylibs, both at the OS level. The 
*Deprecated.dylib would only be included when the application binary was 
compiled using a special -using-deprecated flag that signifies this app needs 
at least one of the deprecated APIs? Then the code signing verification you 
mention wouldn’t be a part of the apps that use deprecated APIs.

If this is not possible because all OS-level .dylibs MUST be included for 
whatever reason then just disregard me, as I’m not an expert on this area of 
Swift.

> On Jan 12, 2018, at 5:43 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> Hi Chris,
> 
> Instead of responding to each of your point bit-by-bit, I’ll try a different 
> tactic to explain my reasoning — which may be wrong — by explaining how I see 
> things top down with the tradeoffs they incur.  I’m going to say a bunch of 
> things I know *you* know, but others are on this thread and I’ll state things 
> for end-to-end clarity.
> 
> It seems to me that we are talking about two possible scenarios: (1) the 
> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
> libswiftCore.dylib into two dylibs, one which includes some of the 
> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits we 
> will see with both scenarios, and see where the mismatch in our “talking past 
> each other” is happening.
> 
> In both cases (A) and (B), with ABI stability the Standard Library has the 
> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
> no longer need to include libswiftCore.dylib in the app when running on an OS 
> that shipped with the Standard Library.
> 
> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
> (B):
> 
> 
> (A) Status quo: Keep shipping everything in libswiftCore.dylib
> 
> - Applications running on an OS with the Standard Library would no longer 
> have *any* of the currently libswift*.dylib’s embedded inside the application 
> bundle because they would just use the one in the OS.
> 
> - One benefit of using libswift*.dylibs in the OS as opposed to those 
> embedded inside the app bundle is that there is a non-neglible startup time 
> improvement, as the code signing verification that happens when an app 
> launches would be faster as it would not need to verify each of these dylibs 
> that were previously embedded in the app.  We should consider this the new 
> baseline for app startup time for an app running on an OS with an ABI stable 
> Standard Library.
> 
> - We continue to support the deprecated APIs for some time, possibly 
> indefinitely, even when better alternatives come around.
> 
> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the 
> app bundle
> 
> In the second scenario, we split out the deprecated APIs into a separate 
> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the 
> following characteristics:
> 
> - Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
> when running on an OS that had an ABI-stable Standard Library.
> 
> - Compared to scenario (A), the OS shipping the Standard Library would have a 
> slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
> deprecated APIs.  This would be a benefit in the code size for the OS, but 
> not for the app itself.
> 
> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside their 
> app bundle.  Compared to the new baseline I mentioned in (A), such apps would 
> have a launch time regression once they started using any API in the 
> libSwiftCoreDeprecated.dylib because code signing would need to verify the 
> dylib, just like it does today with the libswiftCore.dylib that is embedded 
> in every application.  They would also be slightly larger because the app 
> bundle has the burden of hosting libswiftCoreDeprecated.dylib, instead of 
> compared to scenario (A) where the implementations of the deprecated APIs are 
> hosted by the libswiftCore.dylib that ships in the OS.
> 
> - Because of binary compatibility concerns, after Swift 5 we would *never* be 
> able to “take out” any further APIs from libswiftCore.dylib and put them in 
> libswiftCoreDeprecated.dylib.  This factorization can only happen once.
> 
> - There is some slight additional complexity added to the compiler and build 
> system to support this spit of the Standard Library into multiple dylibs.  
> It’s not a huge concern but it does exist and it is not free both in terms of 
> implementing and maintaining.
> 
> - We continue to support the deprecated APIs for some time, possibly 
> indefinitely, even when better alternatives come around.  We *may* be able to 
> completely sunset these APIs by having a future version of the Swift compiler 
> simply refuse to 

Re: [swift-evolution] Core Team vs Random number API discussion

[Jacob Williams via swift-evolution]

> On Dec 6, 2017, at 4:47 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> So, my read of the decision is that when the core teams says the API should 
> be designed “without worrying about the needs of crypto experts,” they mean 
> exactly that we should stop worrying about how easy or hard it is to extend 
> for those users.
> 

Touche. I guess it does mean that, I think it’s a shame to not make something 
like this extensible for pro users. However since it is a small subset of 
people who would probably be able to create their own crypto stuff anyways I 
guess it really doesn’t matter how extensible it is and that the focus should 
be to get something that *most* people will be able to use easily.

> On Wed, Dec 6, 2017 at 18:34 Jacob Williams via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> I agree with this decision, but I would also add the provision that the 
> random number API be designed in such a way that those with special crypto 
> needs can easily extend the existing random number framework to meet their 
> needs. (Specify their own seed, use their own crypto implementation, etc).
> 
> I’m sure this is already being considered having read most of the Random 
> Unification email chain, but just thought I’d make sure it was specifically 
> mentioned. I’d hate to leave a group of coders out in the dark (no matter how 
> small that group may be).
> 
> > On Dec 6, 2017, at 4:16 PM, Chris Lattner via swift-evolution 
> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >
> > Hi All,
> >
> > FYI, the Core Team had a brief discussion about the direction of the random 
> > number API design being discussed.
> >
> > 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.  Such 
> > clients will have requirements that are difficult to predict or that are 
> > hard to provide in general (e.g. “must run in constant time”).  These 
> > clients are also relatively few, compared the community of people who 
> > benefit from a good "general use" random number API.
> >
> > As such, the core team strongly encourages the random number API design 
> > process to focus on building the best possible "general use" API, without 
> > worrying about the needs of crypto experts.
> >
> > Beyond that, the core team did not discuss what the exact shape of the API 
> > should look like: it believes the community should continue hashing it out. 
> >  We just wanted to remove one big constraint from that design process.
> >
> > Thanks,
> >
> > -Chris & Swift Core Team
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <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] Core Team vs Random number API discussion

[Jacob Williams via swift-evolution]

I agree with this decision, but I would also add the provision that the random 
number API be designed in such a way that those with special crypto needs can 
easily extend the existing random number framework to meet their needs. 
(Specify their own seed, use their own crypto implementation, etc).

I’m sure this is already being considered having read most of the Random 
Unification email chain, but just thought I’d make sure it was specifically 
mentioned. I’d hate to leave a group of coders out in the dark (no matter how 
small that group may be).

> On Dec 6, 2017, at 4:16 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi All,
> 
> FYI, the Core Team had a brief discussion about the direction of the random 
> number API design being discussed.
> 
> 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.  Such clients 
> will have requirements that are difficult to predict or that are hard to 
> provide in general (e.g. “must run in constant time”).  These clients are 
> also relatively few, compared the community of people who benefit from a good 
> "general use" random number API.
> 
> As such, the core team strongly encourages the random number API design 
> process to focus on building the best possible "general use" API, without 
> worrying about the needs of crypto experts.
> 
> Beyond that, the core team did not discuss what the exact shape of the API 
> should look like: it believes the community should continue hashing it out.  
> We just wanted to remove one big constraint from that design process.
> 
> Thanks,
> 
> -Chris & Swift Core Team
> 
> 
> ___
> 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: Introduce User-defined "Dynamic Member Lookup" Types

[Jacob Williams via swift-evolution]

> On Dec 4, 2017, at 11:05 AM, Dave DeLong via swift-evolution 
>  wrote:
> 
> Hi Chris,
> 
> We do the Swift integration with Objective-C via modules. Why wouldn’t that 
> approach work with Python? Or if it would, why would we favor this dynamic 
> member lookup over importing a Python API via a module?
> 

My understanding is that we would then have to write modules for each and every 
dynamic language people would want to import. It would take a lot more 
time/maintenance than this approach which theoretically allows for any dynamic 
language to become interoperable with much less effort and very little 
maintenance.

> Dave
> 
>> On Nov 26, 2017, at 11:04 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> I’d like to formally propose the inclusion of user-defined dynamic member 
>> lookup types.
>> 
>> Here is my latest draft of the proposal:
>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
>> https://github.com/apple/swift-evolution/pull/768
>> 
>> An implementation of this design is available here:
>> https://github.com/apple/swift/pull/13076
>> 
>> The implementation is straight-forward and (IMO) non-invasive in the 
>> compiler.
>> 
>> -Chris
>> 
>> ___
>> 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] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Jacob Williams via swift-evolution]

I’ve been going back and forth on whether I’m for or against the current 
revision of the proposal and I’d have to say that I am in favor of it as is for 
the following reasons (many of which have already been stated):

It was stated early on in this proposal that Python is not going to be given 
the same first class support that C/Objective-C have in the compiler. It would 
be unreasonable and would set a precedent that all languages would get the same 
treatment when the community wants to add interoperability. Many arguments have 
been made that we NEED to have static typing for dynamic languages. I don’t see 
static typing coming without first class compiler support. 

Also, the very nature of these dynamic languages means static typing would 
violate basic principles of the dynamic language. I think it would be much 
worse and scare away python developers who are suddenly forced to statically 
type things that they may know to be dynamic types in their python APIs. Of 
course, the other side of the coin is that swift developers would be scared 
away by the lack of static typing when using Python interop. I see the latter 
as a non-issue though because anyone using python knows to expect things 
without static types. 

Forcing static types where there are no static types sounds like a really bad 
idea to me. So I’m ok with the proposed PyVal type for all python types. 
Extensions can be written to make casting a PyVal object to the various swift 
types easy (if/when desired).

There has also been much discussion on the potential for abuse. There was an 
example given of adding conformance to NSObject I believe. Chris and Xiaodi 
both proposed solutions to this that would minimize (and possibly eliminate) 
the potential for abuse. 

However, there will always be potential for a feature to be misused. The 
potential does not mean it is an absolute given that it will be misused (I’m an 
optimist if you can’t tell ;).

I don’t view this protocol as a beginner user feature. This is not a protocol 
that will be commonly used or even commonly desired. It has a very specific set 
of uses and I strongly believe that the community will continue to do a good 
job at suggesting the right tool for the right job. The advanced users that are 
aware of this protocol will most likely properly recommend this protocol when 
applicable. Your average Joe Shmoe isn’t going to even be aware of this. Those 
who are curious, will probably ask about it. There will be StackOverflow 
responses describing it and what it does and when/why to use it. (This is just 
my two cents based on what I’ve witnessed in the swift community and on 
StackOverflow in the past). I’m sure that if the documentation on this protocol 
says “Used to provide interoperability with dynamic languages” then most users 
are going to steer clear of it unless they are writing an interop layer with a 
dynamic language.

I don’t think the goal here is to write Python (or ruby or javascript or 
[dynamic language]) in swift. The aim of this proposal it to make it easy and 
possible to use python from swift. I don’t expect to write a full blown python 
project in swift. I expect to call the few python APIs from module xyz and be 
done with python. I’m trying to write a swift project not a python one. If I 
wanted to use python extensively then I would just stick with python (I work as 
a python developer and Python is definitely not my language of choice, but it 
does have its upsides). I don’t want to write my own swift implementation for 
something where a python module already exists so I import the python module 
and do the few things with it that I actually need. I don’t need or expect IDE 
integration with the language I’m using at that moment. I can read docs for my 
2-3 python API calls while I’m developing it.

Even with this proposal, people could write their own swift libraries that are 
just statically typed wrappers around a python library. This proposal does not 
limit people in any way. It does however, open the door for interoperability 
with a large set of dynamic languages.

> On Dec 1, 2017, at 10:37 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> On Dec 1, 2017, at 12:26 AM, Douglas Gregor  > wrote:
>>> On Nov 30, 2017, at 10:05 PM, Chris Lattner >> > wrote:
>>> Hi Doug,
>>> 
>>> Thank you for the detailed email.  I have been traveling today, so I 
>>> haven’t had a chance to respond until now.  I haven’t read the down-thread 
>>> emails, so I apologize if any of this was already discussed:
>>> 
 I think better interoperability with Python (and other OO languages in 
 widespread use) is a good goal, and I agree that the implementation of the 
 feature described is straight-forward and not terribly invasive in the 
 compiler.
>>> 
>>> Fantastic, I’m really pleased to hear that!  I only care about 

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

[Jacob Williams via swift-evolution]

Huge +1

Dealing with path manipulations via Foundation is a real pain on Linux. I
end up using a lot of C code from Glibc. And random support is another pain
point.

There are tons of uses for a non-std library, however, i would like to see
python style imports (if possible) to avoid importing a potentially large
library when i may only need one or two functions from it. I hate importing
all of foundation just so i csn work with Dates.

Same thing would be handy in a non-std library. I wont do much with
geometry or many other things, but i need a secure random number generator?
`import NonStd.SecureRandom`
Now I’ve got what I need for generating cryptographically secure random
numbers, but none of the additional bloat.

This is probably something that would require an additional proposal, and
I’m not even sure if it would be possible with the way swift compiles
frameworks, but it would be nice


On Wed, Nov 8, 2017 at 5:54 AM Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> FWIW, Ben Cohen and I have been talking about possibly using Swift
> packages as a way to seed out experimental ideas for extensions to the
> Standard Library.  This would allow ideas to be trialed by real usage (a
> complaint I’ve seen about some changes we’ve made to Swift in the past).
> Users could build things on top of those libraries, knowing they are
> available as packages, and if an API “graduates” to being part of the
> Standard Library the user can then depend upon it being available there.
> If it never graduates, however, the package remains around.
>
>
> Yeah this is exactly the problem that the package manager is there to
> solve, right? It’s supposed to make it ridiculously easy to integrate
> libraries and manage your dependencies.
>
> The problem is that most people writing Swift code every day are doing it
> to make graphical applications on iOS/macOS. SwiftPM doesn’t support those,
> so if I want to test a library, it’s just a one-off thing that I play with
> in a Playground.
>
> I think that the best thing we could do to encourage people to write, use
> and contribute to public libraries would be to improve the package manager.
> SwiftPM is still basically a toy (or an interesting curiosity), until it
> can actually be used in the projects most Swift devs get paid to work on
> every day. Talking about it supporting a community is way premature; it’s
> not even close to ready to taking on that responsibility, IMO.
>
> - Karl
> ___
> 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: Remove default initialization of optional bindings

[Jacob Williams via swift-evolution]

> On Nov 6, 2017, at 5:29 PM, Kelvin Ma via swift-evolution 
>  wrote:
> 
> hot take: i use the second one a lot but only because i always forget the 
> first one exists. So I type the = nil just to “be sure”.
> 

Same here! I just changed a bunch of code since I’d forgotten they were the same

> On Mon, Nov 6, 2017 at 4:33 PM, Slava Pestov via swift-evolution 
> > wrote:
> Hi all,
> 
> Right now, the following two declarations are equivalent:
> 
> struct S {
>   var x: Int?
> }
> 
> struct S {
>   var x: Int? = nil
> }
> 
> That is, mutable bindings of sugared optional type (but not Optional!) 
> always have a default value of ‘nil’. This feature increases the surface area 
> of the language for no good reason, and I would like to deprecate it in 
> -swift-version 5 with a short proposal. Does anyone feel strongly about 
> giving it up? I suspect most Swift users don’t even know it exists.
> 
> Slava
> ___
> 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] [Proposal] Random Unification

[Jacob Williams via swift-evolution]

I agree with Dave’s assertion that this should be in a separate Random library. 
Not every project needs random numbers and there could possibly be a 
SecureRandom that exclusively uses CSPRNGs for it’s functionality.

I also agree that trapping is not a preferred behavior. Optionals are slightly 
better, but in many instances the developer doesn’t care if the random number 
is secure or non-reproducible. They really just want some number within a 
specified range that “seems” random enough for that instant. SecureRandom 
numbers could be optional or trap as lacking entropy might significantly effect 
the usage of the random number.


> On Oct 4, 2017, at 10:33 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> Anything that hasn't killed the process seems fine, and you have to start 
> from `main` for anything else. On iOS, you can be suspended at any time, but 
> the program will only continue from the point that it was suspended if it 
> hasn't been torn down; otherwise, it has to restart from the beginning and 
> reload the known UI state that it is responsible for saving. Unless we go out 
> of our way to destroy the PRNG, it won't go away from under the program's 
> feet. I'm not aware of any OS that will core dump programs on shutdown and 
> try to rehydrate them on reboot.
> 
> Félix
> 
>> Le 4 oct. 2017 à 03:05, Xiaodi Wu > > a écrit :
>> 
>> On Wed, Oct 4, 2017 at 04:55 Xiaodi Wu > > wrote:
>> Seems like the API would be actively hiding he possibility of failure so 
>> that you’d have to be in the know to prevent it. Those who don’t know about 
>> it would be hunting down a ghost as they’re trying to debug, especially if 
>> their program crashes rarely, stochastically, and non-reproducibly because a 
>> third party library calls random() in code they can’t see. I think this 
>> makes trapping the least acceptable of all options.
>> 
>> I agree with Felix’s concern, which is why I brought up the question, but 
>> ultimately the issue is unavoidable. It’s not down to global instance or 
>> not. If your source of random numbers is unseedable and may mix in 
>> additional entropy at any time, then it may fail at any time because when a 
>> hardware restart might happen may be transparent to the process. The user 
>> must know about this or else we are laying a trap (pun intended).
>> 
>> On Wed, Oct 4, 2017 at 04:49 Jonathan Hull > > wrote:
>> @Xiaodi:  What do you think of the possibility of trapping in cases of low 
>> entropy, and adding an additional global function that checks for entropy so 
>> that conscientious programmers can avoid the trap and provide an alternative 
>> (or error message)?
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> On Oct 4, 2017, at 2:41 AM, Xiaodi Wu >> > wrote:
>>> 
>>> 
>>> On Wed, Oct 4, 2017 at 02:39 Félix Cloutier >> > wrote:
>>> I'm really not enthusiastic about `random() -> Self?` or `random() throws 
>>> -> Self` when the only possible error is that some global object hasn't 
>>> been initialized.
>>> 
>>> The idea of having `random` straight on integers and floats and collections 
>>> was to provide a simple interface, but using a global CSPRNG for those 
>>> operations comes at a significant usability cost. I think that something 
>>> has to go:
>>> 
>>> Drop the random methods on FixedWidthInteger, FloatingPoint
>>> ...or drop the CSPRNG as a default
>>> Drop the optional/throws, and trap on error
>>> 
>>> I know I wouldn't use the `Int.random()` method if I had to unwrap every 
>>> single result, when getting one non-nil result guarantees that the program 
>>> won't see any other nil result again until it restarts.
>>> 
>>> From the perspective of an app that can be suspended and resumed at any 
>>> time, “until it restarts” could be as soon as the next invocation of 
>>> `Int.random()`, could it not?
>>> 
>>> 
>>> Félix
>>> 
 Le 3 oct. 2017 à 23:44, Jonathan Hull > a écrit :
 
 I like the idea of splitting it into 2 separate “Random” proposals.
 
 The first would have Xiaodi’s built-in CSPRNG which only has the interface:
 
 On FixedWidthInteger:
static func random()throws -> Self
static func random(in range: ClosedRange)throws -> Self
 
 On Double:
static func random()throws -> Double
static func random(in range: ClosedRange)throws -> Double
 
 (Everything else we want, like shuffled(), could be built in later 
 proposals by calling those functions)
 
 The other option would be to remove the ‘throws’ from the above functions 
 (perhaps fatalError-ing), and provide an additional function which can be 
 used to check that there is enough entropy 

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

[Jacob Williams via swift-evolution]

What if we did it with something like this:

protocol RandomGenerator {
associated type T: Numeric // Since numeric types are the only kinds 
where we could get a random number?
func uniform() -> T
// Other random type functions...
}

Although if we didn’t constrain T to Numeric then collections could also 
conform to it, although I’m not sure that collections would want to directly 
conform to this. There may need to be a separate protocol for types with 
Numeric indexes?

I’m no pro and really haven’t thought about this too deeply. Mostly just 
spitballing/brainstorming.

> On Sep 8, 2017, at 3:03 PM, Jacob Williams via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Huge +1 to stdlib (or even Foundation) random number generator. I’ve worked 
> with random numbers on both Linux and macOS/iOS and have found myself annoyed 
> with the lack of easy random number generators. It seems that implementing a 
> pure Swift RNG would be an obviously good addition to the stdlib.
> 
> I don’t think that it would be possible to make this work for floating point 
> numbers. Although admittedly, I know very little about Floating Point 
> numbers. I think this is still a worthwhile addition to Swift even for just 
> Integers alone.
> 
>> On Sep 8, 2017, at 1:30 PM, Ben Cohen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi Alejandro,
>> 
>> I’m really happy to see someone pick this up. We had suggested some kind of 
>> random support could be a goal for addition to the standard library in Swift 
>> 4 phase 2 but didn’t manage it, so I definitely think a good proposal would 
>> be given consideration for Swift 5.
>> 
>> Regarding the implementation – I would suggest exploring something along the 
>> lines of an extension on RandomAccessCollection that adds a property for a 
>> random element, rather than a pair of free functions. This would have a 
>> number of benefits:
>> 
>>  - a very common use case is picking a random entry from a collection, which 
>> this would do automatically
>>  - it gives you a very natural way of expressing a ranged random number i.e. 
>> (0..<10).randomElement (not necessarily recommending that name btw, it’s one 
>> of various possibilities)
>>  - since both kinds of countable ranges are collections, it sidesteps that 
>> issue :)
>>  - it allows for multiple different integers without the need for casting 
>> i.e. in the above, if type context meant the result was a UInt16, that’s 
>> what it would be
>> 
>> The one downside is that you’d have to write (0..<Int.max). This might be a 
>> justification for a static property on one of the Integer protocols as 
>> shorthand for that.
>> 
>> The tricky part (in addition to the cross-platform aspect) is ensuring 
>> correct distribution across the possible distances. But since this is 
>> something that people might easily get wrong, that reinforces the idea of 
>> this being something that’s easy to use correctly in the std lib.
>> 
>> I’d also suggest proposing a shuffle implementation for 
>> RandomAccessCollection+MutableCollection at the same time (probably as a 
>> separate but linked proposal), since this is also something that is often 
>> requested, easy to get wrong, and needs a cross-platform source of random 
>> numbers.
>> 
>> Regards,
>> Ben
>> 
>> 
>>> On Sep 8, 2017, at 10:34 AM, Alejandro Alonso via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Range support is something that came up, and I think it’s a great idea as 
>>> well. My question now is do we support both `CountableRange` and 
>>> `CountableClosedRange`?
>>> 
>>> On Sep 8, 2017, 12:08 PM -0500, Shawn Erickson <shaw...@gmail.com 
>>> <mailto:shaw...@gmail.com>>, wrote:
>>>> It would be nice to leverage range support instead of a start and end 
>>>> value IMHO.
>>>> On Fri, Sep 8, 2017 at 9:52 AM Alejandro Alonso via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> Hello swift evolution, I would like to propose a unified approach to 
>>>> `random()` in Swift. I have a simple implementation here 
>>>> https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5 
>>>> <https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5>. This 
>>>> implementation is a simple wrapper over existing random functions so 
>>>>

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

[Jacob Williams via swift-evolution]

Huge +1 to stdlib (or even Foundation) random number generator. I’ve worked 
with random numbers on both Linux and macOS/iOS and have found myself annoyed 
with the lack of easy random number generators. It seems that implementing a 
pure Swift RNG would be an obviously good addition to the stdlib.

I don’t think that it would be possible to make this work for floating point 
numbers. Although admittedly, I know very little about Floating Point numbers. 
I think this is still a worthwhile addition to Swift even for just Integers 
alone.

> On Sep 8, 2017, at 1:30 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi Alejandro,
> 
> I’m really happy to see someone pick this up. We had suggested some kind of 
> random support could be a goal for addition to the standard library in Swift 
> 4 phase 2 but didn’t manage it, so I definitely think a good proposal would 
> be given consideration for Swift 5.
> 
> Regarding the implementation – I would suggest exploring something along the 
> lines of an extension on RandomAccessCollection that adds a property for a 
> random element, rather than a pair of free functions. This would have a 
> number of benefits:
> 
>  - a very common use case is picking a random entry from a collection, which 
> this would do automatically
>  - it gives you a very natural way of expressing a ranged random number i.e. 
> (0..<10).randomElement (not necessarily recommending that name btw, it’s one 
> of various possibilities)
>  - since both kinds of countable ranges are collections, it sidesteps that 
> issue :)
>  - it allows for multiple different integers without the need for casting 
> i.e. in the above, if type context meant the result was a UInt16, that’s what 
> it would be
> 
> The one downside is that you’d have to write (0.. justification for a static property on one of the Integer protocols as 
> shorthand for that.
> 
> The tricky part (in addition to the cross-platform aspect) is ensuring 
> correct distribution across the possible distances. But since this is 
> something that people might easily get wrong, that reinforces the idea of 
> this being something that’s easy to use correctly in the std lib.
> 
> I’d also suggest proposing a shuffle implementation for 
> RandomAccessCollection+MutableCollection at the same time (probably as a 
> separate but linked proposal), since this is also something that is often 
> requested, easy to get wrong, and needs a cross-platform source of random 
> numbers.
> 
> Regards,
> Ben
> 
> 
>> On Sep 8, 2017, at 10:34 AM, Alejandro Alonso via swift-evolution 
>> > wrote:
>> 
>> Range support is something that came up, and I think it’s a great idea as 
>> well. My question now is do we support both `CountableRange` and 
>> `CountableClosedRange`?
>> 
>> On Sep 8, 2017, 12:08 PM -0500, Shawn Erickson > >, wrote:
>>> It would be nice to leverage range support instead of a start and end value 
>>> IMHO.
>>> On Fri, Sep 8, 2017 at 9:52 AM Alejandro Alonso via swift-evolution 
>>> > wrote:
>>> Hello swift evolution, I would like to propose a unified approach to 
>>> `random()` in Swift. I have a simple implementation here 
>>> https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5 
>>> . This 
>>> implementation is a simple wrapper over existing random functions so 
>>> existing code bases will not be affected. Also, this approach introduces a 
>>> new random feature for Linux users that give them access to upper bounds, 
>>> as well as a lower bound for both Glibc and Darwin users. This change would 
>>> be implemented within Foundation.
>>> 
>>> I believe this simple change could have a very positive impact on new 
>>> developers learning Swift and experienced developers being able to write 
>>> single random declarations.
>>> 
>>> I’d like to hear about your ideas on this proposal, or any implementation 
>>> changes if need be.
>>> 
>>> - Alejando
>>> 
>>> ___
>>> 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 mailing list
swift-evolution@swift.org

Re: [swift-evolution] (core library) modern URL types

[Jacob Williams via swift-evolution]

There’s also a library somewhat similar to PathKit called FileKit 
(https://github.com/nvzqz/FileKit ). FileKit 
has some functionality I’m not sure how I feel about, such as different types 
based on the type of data in the file. It also uses a lot of Foundation for 
NSBacked types which breaks Linux compatibility. 

I do agree that URL is not the best option for file paths, despite many of the 
similarities with URL paths, and agree that much of Foundation should be ported 
to pure Swift in order to increase linux compatibility. 

> On Aug 22, 2017, at 10:25 AM, Dave DeLong via swift-evolution 
>  wrote:
> 
> I completely agree. URL packs a lot of punch, but IMO it’s the wrong 
> abstraction for file system paths.
> 
> I maintain an app that deals a lot with file system paths, and using URL has 
> always felt cumbersome, but String is the absolute wrong type to use. Lately 
> as I’ve been working on it, I’ve been experimenting with a concrete “Path” 
> type, similar to PathKit (https://github.com/kylef/PathKit/ 
> ). Working in terms of AbsolutePath and 
> RelativePath (what I’ve been calling things) has been extremely refreshing, 
> because it allows me to better articulate the kind of data I’m dealing with. 
> URL doesn’t handle pure-relative paths very well, and it’s always a bit of a 
> mystery how resilient I need to be about checking .isFileURL or whatever. All 
> the extra properties (port, user, password, host) feel hugely unnecessary as 
> well.
> 
> Dave
> 
>> On Aug 20, 2017, at 11:23 PM, Félix Cloutier via swift-evolution 
>> > wrote:
>> 
>> I'm not convinced that URLs are the appropriate abstraction for a file 
>> system path. For the record, I'm not a fan of existing Foundation methods 
>> that create objects from an URL. There is a useful and fundamental 
>> difference between a local path and a remote path, and conflating the two 
>> has been a security pain point in many languages and frameworks that allow 
>> it. Examples include remote file inclusion in PHP and malicious doctypes in 
>> XML. Windows also had its share of issues with UNC paths.
>> 
>> Even when loading an arbitrary URL looks innocuous, many de-anonymizing 
>> hacks work by causing a program to access an URL controlled by an attacker 
>> to make it disclose the user's IP address or some other identifier.
>> 
>> IMO, this justifies that there should be separate types to handle local and 
>> remote resources, so that at least developers have to be explicit about 
>> allowing remote resources. This makes a new URL type less necessary towards 
>> supporting file I/O.
>> 
>> Félix
>> 
>>> Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution 
>>> > a écrit :
>>> 
>>> Okay so a few days ago there was a discussion 
>>> 
>>>  about getting pure swift file system support into Foundation or another 
>>> core library, and in my opinion, doing this requires a total overhaul of 
>>> the `URL` type (which is currently little more than a wrapper for NSURL), 
>>> so I’ve just started a pure Swift URL library project at 
>>> >.
>>> 
>>> The library’s parsing and validation core (~1K loc pure swift) is already 
>>> in place and functional; the goal is to eventually support all of the 
>>> Foundation URL functionality.
>>> 
>>> The new `URL` type is implemented as a value type with utf8 storage backed 
>>> by an array buffer. The URLs are just 56 bytes long each, so they should be 
>>> able to fit into cache lines. (NSURL by comparison is over 128 bytes in 
>>> size; it’s only saved by the fact that the thing is passed as a reference 
>>> type.)
>>> 
>>> As I said, this is still really early on and not a mature library at all 
>>> but everyone is invited to observe, provide feedback, or contribute!
>>> ___
>>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift source mentorship program

[Jacob Williams via swift-evolution]

A Swift developer has actually started a blog series about the swift compiler. 
The links to his post were posted in one of the evolution topics a little while 
ago. The series is incomplete, but it gives a lot of explanations about the 
various parts of the swift compiler.

https://medium.com/@slavapestov/the-secret-life-of-types-in-swift-ff83c3c000a5 

https://medium.com/@slavapestov/how-to-talk-to-your-kids-about-sil-type-use-6b45f7595f43
 


I wholeheartedly agree that a mentorship program would be extremely useful for 
helping others get up-to-speed with the swift compiler. I myself wished I 
understood it better. The only problem is that with something so large and 
complex, it would take a lot of time and effort to document and create a 
tutorial for it. I wish that this would happen, but I don’t know that anyone at 
Apple has the time and there probably aren’t very many people outside of apple 
with the know-how and time to write a tutorial as a hobby. I hope that I’m 
wrong though.


> On Aug 14, 2017, at 2:35 PM, Jay Abbott via swift-evolution 
>  wrote:
> 
> I think we should have some kind of mentorship program for the swift source. 
> I'm confident that my following statement doesn't apply to just me:
> 
> "I'd love to get involved in the source a lot more, and my previous efforts 
> to browse around and understand it a bit better have been thwarted by lack of 
> time, a specific goal/direction, and no proper commitment (all my own 
> failings of course). I'd be happy to learn the code and implement proposals, 
> but I really want someone to turn to when I need some help and guidance."
> 
> In addition to the core team, I think there are a few others who know the 
> code well enough, and who may be willing to mentor and share that knowledge 
> further. Having a specific mentor makes it much easier to get to a level 
> where you feel comfortable talking to the wider development community on 
> swift-dev for example.
> 
> There would need to be some level of self-starting bar, which would need to 
> be supported by some documentation to read, and some simple tasks/tutorials 
> to complete (For example create a branch which removes an existing feature 
> and a tutorial to re-implement it, that touches a few key areas of the 
> code-base). The swift project and the evolution process would benefit by 
> having more potential implementors, so writing such documentation and 
> getting-started guides should be a high priority in order to help people get 
> more involved. Once complete, it would be great to choose a proposal, find a 
> mentor, and start work on it under their guidance.
> 
> I believe effort focused in this area will have a high return, given the high 
> quality and quantity of passion and talent I see in this list.
> ___
> 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: Regular Expression in Swift

[Jacob Williams via swift-evolution]

Disclaimer: I am not well versed in the various complexities of regex 
implementations.

That being said, I would very much like to see better regex support in Swift. 
Preferably one that is easier to pick up than the NSRegularExpression of ObjC 
and possibly as easy to start using as python or ruby.

Just some things to consider for the implementation:

- Plain old searching for a match
- Multiple (named) capture groups
- I liked the suggestion of binding straight to variables (perhaps with 
closures)
- Replacements
- I’m also not a fan of using the backslash for instantiating a regex literal. 
Many other languages use the forward slash (Off the top of my head all I can 
think of is Ruby, but I’m sure there are others)


> On Aug 10, 2017, at 4:28 AM, Omar Charif via swift-evolution 
>  wrote:
> 
> Hi Joshua,
> 
> I also feel a huge gap when it comes to string matching, whether it is 
> implementation or performance.
> I also wrote a library for String matching called StringMap and it has been 
> way for performant than regular expressions.
> I recently proposed to include it in core foundation but it seems that I was 
> a bit late and the team was busy finishing their unimplemented functions so 
> they advised me to ship the code in SPM instead.
> So I am also willing to work in this issue.
> 
> 
> 
> 
>> On Aug 10, 2017, at 8:25 AM, Joshua Alvarado via swift-evolution 
>> > wrote:
>> 
>> Hey everyone,
>> 
>> I would like to pitch an implementation of Regex in Swift and gather all of 
>> your thoughts.
>> 
>> Motivation:
>> In the String Manifesto for Swift 4, addressing regular expressions was not 
>> in scope. Swift 5 would be a more fitting version to address the 
>> implementation of Regex in Swift. NSRegularExpression is a suitable solution 
>> for pattern matching but the API is in unfitting for the future direction of 
>> Swift.
>> 
>> Implementation:
>> The Regular expression API will be implemented by a Regex structure object 
>> which is a regular expression that you can apply to Unicode strings. The 
>> Regex struct will conform to the RegexProtocol, which is a type that can 
>> represent a regular expression. ExpressibleByRegexLiteral will be used to 
>> initialize a regex literal creating an easy to use syntax and a Match 
>> structure will be used to represent a match found with a Regex.
>> 
>> Draft of implementation:
>> 
>> protocol ExpressibleByRegexLiteral {
>> associatedtype RegexLiteralType
>> 
>> init(regexLiteral value: Self.RegexLiteralType)
>> }
>> 
>> // Structure of information about a match of regex on a string
>> struct Match {
>> var regex: Regex
>> var start: String.Index
>> var end: String.Index
>> }
>> 
>> protocol RegexProtocol {
>> init(pattern: String) throws
>> 
>> var pattern: String { get } // string representation of the pattern
>> func search(string: String) -> Bool // used to check if a match is found 
>> at all in the string
>> func match(string: String) -> [Match] // returns an array of all the 
>> matches
>> func match(string: String, using: ((Match) -> Void)) // enmuerate over 
>> matches
>> }
>> 
>> struct Regex: RegexProtocol {
>> init(pattern: Regex, options: Regex.Options)
>> let options: [Regex.Options]
>> static let word: Regex // \w
>> // other useful regexes can be added as well
>> }
>> 
>> // Examples
>> 
>> let regex = \[a-zA-Z]+\
>> let matches = regex.match("Matching words in text.")
>> 
>> for match in matches {
>> print("Found a match at in string at \(match.start) to \(match.end)")
>> }
>> 
>> let helloStr = "Hello world"
>> 
>> Regex.word.match(helloStr) { match in
>> print("Matched \(helloStr[match.start..> }
>>  
>> Of course this is a scratch implementation I made but it is to open 
>> discussion on the topic. I feel the Regex struct itself will need more 
>> methods and variables such as for flags and number of groups. Please provide 
>> feedback with improvements to the code, concerns on the topic, or just open 
>> up discussion. Thank you!
>> 
>> Joshua Alvarado
>> alvaradojosh...@gmail.com 
>> 
>> ___
>> 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] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Jacob Williams via swift-evolution]

There’s also a PureSwift organization of GitHub that has several Swift PM 
packages built specifically with Linux support in mind

https://github.com/PureSwift 

It looks like it’s along the lines of SwiftBreezy, but it hasn’t died out…yet.

At the same time, this may just be another example of how without an Apple 
“backed”/supported repo, the community is very likely to become more and more 
fragmented as more and more people implement the same few frameworks with minor 
variations/improvements.

> On Aug 3, 2017, at 5:04 AM, Stephen Canon via swift-evolution 
>  wrote:
> 
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> It’s important to remember that computers are mathematical machines, and 
>> some functions which are implemented in hardware on essentially every 
>> platform (like sin/cos/etc) are definitely best implemented as compiler 
>> intrinsics.
> 
> sin/cos/etc are implemented in software, not hardware. x86 does have the 
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement 
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow 
> and too inaccurate for serious use today. There are no analogous instructions 
> on ARM or PPC.
> 
> – Steve
> ___
> 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] Change 'for in' expression to for [] { (item) in ... }

[Jacob Williams via swift-evolution]

This change would also make it so that for loops follow the same format as all 
other closures with variables.

The downside is that this would break a TON of code. I don’t think that the 
amount of code this breaks would be worth the consistency. And as Alex 
mentioned, it is possible through .forEach


> On Jul 28, 2017, at 10:19 AM, Kwanghoon Choi via swift-evolution 
>  wrote:
> 
> Hello
> 
> I found someone easy mistake using for in loop statement.
> 
> Ex)
> var i = 0
> for i in 0..<10 { }
> print(i)
> 
> And this user expected print(i) is “10”
> 
> Many experienced swift developers doesn’t misunderstand like this. But always 
> someone is new comers, and I think this expression make misunderstand easy 
> too.
> 
> So why not like this?
> 
> var I = 0
> for 0..<10 { (i) in … }
> 
> I think this is more understandable for loop expression. 
> 
> Best Regards
> 
> - Jay Choi
> ___
> 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] [idea] errors in properties

[Jacob Williams via swift-evolution]

I’d give my +1 to support this as I’ve wished at one time or another that I 
could throw in the get, set, willSet, or didSet.

Would this be something a proposal should be written up for when the Swift 5 
reviews begin?

> On Jul 25, 2017, at 2:55 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> There have been a number of discussions on the list in this—Google finds a 
> number of these with a search “swift throwing properties site:lists.swift.org 
> ”.
> 
> The “tldr” seems to be that it’s not supported because no one has written 
> code to support it yet.
> On Tue, Jul 25, 2017 at 15:29 Gor Gyolchanyan via swift-evolution 
> > wrote:
> I’ll just cut to the chase:
> Why is throwing from get, set, willSet and didSet disallowed?
> 
> var login: String {
>   willSet throws {
>   guard newValue.count > 5 else {
>   throw LoginError.loginTooSmall
>   }
>   }
> }
> 
> try login = “JebediahKerman” // totally fine
> try login = “Bob” // throws `LoginError.loginTooSmall`
> 
> ___
> 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] JIT compilation for server-side Swift

[Jacob Williams via swift-evolution]

Pardon my lack of knowledge about JIT compilation, but does this open the realm 
of possibilities to a client-side swift that would allow web developers to 
write swift code rather than javascript?

> On Jul 10, 2017, at 10:40 AM, Younes Manton via swift-evolution 
>  wrote:
> 
> Hi,
> 
> Last year a small group of developers from the IBM Runtimes compiler team 
> undertook a project to explore JIT compilation for Swift, primarily aimed at 
> server-side Swift. The compilation model we settled on was a hybrid approach 
> that combined static compilation via swiftc with dynamic compilation via a 
> prototype JIT compiler based on Eclipse OMR.[1]
> 
> This prototype JIT compiler (targeting Linux specifically) functioned by 
> having itself loaded by a Swift process at runtime, patching Swift functions 
> so that they may be intercepted, recompiling them from their SIL 
> representations, and redirecting callers to the JIT compiled version. In 
> order to accomplish this we needed to make some changes to the static 
> compiler and the target program's build process.
> 
> * First, we modified the compiler to emit code at the beginning of main() 
> that will attempt to dlopen() the JIT compiler, and if successful, call its 
> initialization routine. If unsuccessful the program would simply carry on 
> executing the rest of main().
> 
> * Second, we modified all Swift functions to be patchable by giving them the 
> "patchable-function" LLVM attribute (making the first instruction suitable to 
> be patched over with a short jump) and attaching 32 bytes of prefix data 
> (suitable to hold a long jump to a JIT hook function and some extra data) to 
> the function's code. This was controlled by a frontend "-enable-jit" switch.
> 
> * Third, when building the target program we first compiled the Swift sources 
> to a .sib (binary SIL) file, then via ld and objcopy turned the .sib into a 
> .o containing a .sib data section, then compiled the sources again into an 
> executable, this time linking with the .o containing the binary SIL. This 
> embedded SIL is what was consumed at runtime by the JIT compiler in order to 
> recompile Swift functions on the fly. (Ideally this step would be done by the 
> static compiler itself (and is not unlike the embedding of LLVM bitcode in a 
> .llvmbc section), but that would have been a significant undertaking so for 
> prototyping purposes we did it at target program build time.)
> 
> That's the brief, high level description of what we did, particularly as it 
> relates to the static side of this hybrid approach. The resulting prototype 
> JIT was able to run and fully recompile a non-trivial (but constrained) 
> program at comparable performance to the purely static version. For anyone 
> interested in more details about the project as a whole, including how the 
> prototype JIT functioned, the overhead it introduced, and the quality of code 
> it emitted, I'll point you to Mark Stoodley's recent tech talk.[2]
> 
> Having said that, it is with the static side in mind that I'm writing this 
> email. Despite the prototype JIT being built on OMR, the changes to the 
> static side outlined above are largely compiler agnostic APIs/ABIs that 
> anyone can use to build similar hybrid JITs or other runtime tools that make 
> sense for the server space. As such, we felt that it was a topic that was 
> worth discussing early and in public in order to allow any and all 
> potentially interested parties an opportunity to weigh in. With this email we 
> wanted to introduce ourselves to the wider Swift community and solicit 
> feedback on 1) the general idea of JIT compilation for server-side Swift, 2) 
> the hybrid approach in particular, and 3) the changes mentioned above and 
> future work in the static compiler to facilitate 1) and 2). To that end, we'd 
> be happy to take questions and welcome any discussion on this subject.
> 
> (As for the prototype itself, we intend to open source it either in its 
> current state [based on Swift 3.0 and an early version of OMR] or in a more 
> up-to-date state in the very near future.)
> 
> Thank you kindly,
> Younes Manton
> 
> [1] http://www.eclipse.org/omr/  & 
> https://github.com/eclipse/omr 
> [2] http://www.ustream.tv/recorded/105013815 
>  (Swift JIT starts at ~28:20)
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Jacob Williams via swift-evolution]

I have been persuaded that extending the capabilities of the current ?? 
operator has far more advantages than adding a new limited !! operator. While I 
initially did not like the usage of the generally-assumed-safe ? for throwing 
operations, the clarity provided by having to explicitly state your 
‘fatalError’ or ‘preconditionFailure’ etc, does make it obvious about what is 
going on. 

Also, considering how this capability would eventually be possible with ?? 
anyways once Never become a true bottom type, it does not make sense to add a 
new operator that would essentially become deprecated in a short matter of time 
anyways. As many people have stated, the bar for additions to the Swift 
language should be, and is, exceptionally high. There just aren’t enough pro’s 
for the !! operator to make it worthwhile.

> On Jun 30, 2017, at 9:31 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> These are all excellent points. I also feel they sidestep the motivation of 
> the proposal. Even if there were a bottom `Never` and you could use `?? 
> fatalError()`, I still think the language would benefit from `!!`.
> 
> As the language is right now, you can write your own "or die" function using 
> a `guard` statement, overloading `??`, or implementing `!!`. Being able to 
> duplicate an explanatory fail path isn't the point. Offering a best-practices 
> alternative to `!!` that is easy to use, obvious to understand, and simple to 
> adopt is.
> 
> As for the `#line` and `#file` issue, that is my biggest concern but I 
> believe that can be surmounted.
> 
> -- E
> 
> 
> 
>> On Jun 29, 2017, at 11:23 PM, Brent Royal-Gordon > > wrote:
>> 
>>> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
>>> > wrote:
>>> 
>>> Using an operator to provide feedback on the context of a failed unwrap has 
>>> become a commonly implemented approach in the Swift developer Community. 
>>> What are your thoughts about adopting this widely-used operator into the 
>>> standard library?
>>> 
>>> guard !lastItem.isEmpty else { return }
>>> let lastItem = array.last !! "Array must be non-empty"
>>> 
>>> Details here:  
>>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>>> 
>>> 
>>> Thank you for your thoughtful feedback, -- E
>> 
>> Finally found a few minutes to read this thread.
>> 
>> I'm a big fan of the `Never`-based approach. (I was before, but I am more so 
>> now.) Here are the points I can see in its favor:
>> 
>> 1. It is extremely clear about what's happening—`!!` is another random 
>> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
>> fairly self-explanatory, and `??` is something you might already be using.
>> 
>> 2. It allows you to control the optimization behavior by using `fatalError`, 
>> `preconditionFailure`, or `assertionFailure` as desired.
>> 
>> 3. If we later change `throw` from being a statement to being a 
>> `Never`-returning expression, you could use `throw` on the right-hand side 
>> of `??`.
>> 
>> 4. It supports other `Never`-returning operations, like `abort()` or 
>> `exit(_:)` or your custom `usage()` function, on the right side of `??`.
>> 
>> 5. It supports file-and-line error reporting without having to add any new 
>> features; `!!` could not do this because an operator can't have extra, 
>> defaulted parameters to carry the file and line.
>> 
>> 6. It harmonizes with the eventual idea of making `Never` a universal bottom 
>> type, but we don't actually have to implement that today, because we can 
>> just overload `??` for now.
>> 
>> Against these advantages, the only one I can see for `!!` is that it is 
>> terse. Terseness is good, especially for a feature which is competing with 
>> the single-character postfix `!` operator, but I can't help but be drawn to 
>> the flexibility and power of `??` with a `Never` expression on the 
>> right-hand side.
>> 
>> -- 
>> 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] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Jacob Williams via swift-evolution]

> On Jun 28, 2017, at 10:13 AM, Tony Allevato <tony.allev...@gmail.com> wrote:
> 
> It's hard for me to articulate, but "foo !! message" feels a little too much 
> like a Perl-ism for my taste. Objectively that's not a great criticism on its 
> own, but I just don't like the "smell" of an operator that takes a value on 
> one side and a string for error reporting purposes on the other. It doesn't 
> feel like it fits the style of Swift. I prefer a version that makes the call 
> to fatalError (and thus, any other non-returning handler) explicitly written 
> out in code.
> 
> So, if the language can already support this with ?? and autoclosure/Never as 
> was shown above, I'd rather see that added to the language instead of a new 
> operator that does the same thing (and is actually less general).

I do see your point, and pardon my lack of familiarity with deeper swift 
capabilities, but would it be possible to restrict the !! operator to @noreturn 
closures rather than a string and just always throwing a fatalError? This would 
require the !! operator to have the error type explicitly spelt out, while 
still honoring the sentiment of !. It would feel more swifty, and you’d get the 
clarity of knowing that !! is an unsafe operation and you’d know exactly what 
kind of error is being thrown.

And then ?? could be left as-is and only used for default values.

> 
> On Wed, Jun 28, 2017 at 8:52 AM Jacob Williams via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> I feel that the !! operator would be necessary for indicating that if this 
> fails then something went horribly wrong somewhere and we should throw the 
> fatalError. This allows the inclusion of optimizations using -Ounchecked and 
> is clear that this is an operation that could result in a runtime error just 
> like force unwrapping.
> 
> If we want code clarity and uniformity, then I think !! Is much better than 
> ?? because it goes right along with the single ! Used for force unwrapping. 
> However, this does depend on if the operator would be returning some kind of 
> error that would cause the program to exit.
> 
> I think the ?? operator should not cause a program to exit early. It goes 
> against optional unwrapping principles. I think code could get very confusing 
> if some ? would return nil/a default value, and others would be causing your 
> program to crash and exit. The ? operators should always be classified as 
> safe operations.
> 
>> On Jun 28, 2017, at 9:41 AM, Ben Cohen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Count me in as a strong proponent of ?? () -> Never. We don't need to 
>>> burden the language with an extra operator just for that.
>> 
>> You could say the same about ??
>> 
>> The concern that an additional operator (and one that, IMO, fits well into 
>> existing patterns) is so burdensome seems way overweighted in this 
>> discussion IMO. 
>> 
>> Adding the operator, and encouraging its use, will help foster better 
>> understanding of optionals and legitimate use of force-unwrapping in a way 
>> that I don’t think `?? fatalError` could.
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <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] Introducing the "Unwrap or Die" operator to the standard library

[Jacob Williams via swift-evolution]

I feel that the !! operator would be necessary for indicating that if this 
fails then something went horribly wrong somewhere and we should throw the 
fatalError. This allows the inclusion of optimizations using -Ounchecked and is 
clear that this is an operation that could result in a runtime error just like 
force unwrapping.

If we want code clarity and uniformity, then I think !! Is much better than ?? 
because it goes right along with the single ! Used for force unwrapping. 
However, this does depend on if the operator would be returning some kind of 
error that would cause the program to exit.

I think the ?? operator should not cause a program to exit early. It goes 
against optional unwrapping principles. I think code could get very confusing 
if some ? would return nil/a default value, and others would be causing your 
program to crash and exit. The ? operators should always be classified as safe 
operations.

> On Jun 28, 2017, at 9:41 AM, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution 
>> > wrote:
>> 
>> Count me in as a strong proponent of ?? () -> Never. We don't need to burden 
>> the language with an extra operator just for that.
> 
> You could say the same about ??
> 
> The concern that an additional operator (and one that, IMO, fits well into 
> existing patterns) is so burdensome seems way overweighted in this discussion 
> IMO. 
> 
> Adding the operator, and encouraging its use, will help foster better 
> understanding of optionals and legitimate use of force-unwrapping in a way 
> that I don’t think `?? fatalError` could.
> 
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Jacob Williams via swift-evolution]

+1 to Adrians implementation. While I like the sugar of both, I don’t think the 
operator should necessarily always cause a fatalError. Maybe we could use both 
the !! For some kind of fatal error and Adrians !? To just use @noreturn to 
leave the current function.

> On Jun 27, 2017, at 11:29 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> +1 I had a slightly different implementation.
> 
> https://gist.github.com/DevAndArtist/dad641ee833e60b02fd1db2dbb488c6a 
> 
> //
> // UnwrapOrTrap.swift
> //
> infix operator ?! : NilCoalescingPrecedence
> 
> /// Performs a nil-coalescing operation, returning the wrapped value of an
> /// `Optional` instance or uses the rhs function to stop the program.
> ///
> /// - Parameters:
> ///   - optional: An optional value.
> ///   - noreturn: A function to stop the programm.
> func ?!(optional: T?, noreturn: @autoclosure () -> Never) -> T {
>switch optional {
>case .some(let value):
>   return value
>case .none:
>   noreturn()
>}
> }
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 27. Juni 2017 um 19:25:15, Erica Sadun via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Using an operator to provide feedback on the context of a failed unwrap has 
>> become a commonly implemented approach in the Swift developer Community. 
>> What are your thoughts about adopting this widely-used operator into the 
>> standard library?
>> 
>> guard !lastItem.isEmpty else { return }
>> let lastItem = array.last !! "Array must be non-empty"
>> 
>> Details here:  
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>> 
>> 
>> Thank you for your thoughtful feedback, -- 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 
> 

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

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

[Jacob Williams via swift-evolution]

> On Jun 9, 2017, at 9:53 AM, Charlie Monroe <char...@charliemonroe.net> wrote:
> 
> -1 - this would disallow e.g. to share UI code between iOS and macOS:
> 
> #if os(iOS)
>   typealias XUView = UIView
> #else
>   typealias XUView = NSView
> #endif
> 
> extension XUView {
>   ...
> }

I really don’t see how this disallows code sharing between the two systems? 
Could you explain further? Based on my understanding of the pitch, this is 
valid code still. (Although I do like the suggestion of a new keyword rather 
than just limiting type alias).

Even if your example was invalid, you could also just do something like this:

#if os(iOS)
typealias XUView = UIView
extension XUView {
//extension code here
}
#if os(macOS)
typealias XUView = UIView
extension XUView {
// extension code here
}
#endif

While not as pretty, still just as effective if you have to deal with different 
types based on the system being compiled for and you could easily still make 
the type alias extensions for each type work the same.

> On Jun 9, 2017, at 9:53 AM, Charlie Monroe <char...@charliemonroe.net> wrote:
> 
> -1 - this would disallow e.g. to share UI code between iOS and macOS:
> 
> #if os(iOS)
>   typealias XUView = UIView
> #else
>   typealias XUView = NSView
> #endif
> 
> extension XUView {
>   ...
> }
> 
> or with any similar compatibility typealiases.
> 
>> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> +1 from me.
>> 
>> There have been times I’ve wanted to subclass an object (such as String) but 
>> since it is a non-class, non-protocol type you can only extend Strings 
>> existing functionality which adds that same functionality to Strings 
>> everywhere. It would be nice if we could either extend type aliases (and 
>> only the type alias), or if it were possible to inherit from structs so that 
>> we could create a custom string type like so:
>> 
>> struct HeaderKey: String {
>>  static var lastModified: String { return “Last-Modified” }
>>  static var host: String { return “Host” }
>> }
>> 
>> I realize that struct inheritance is far less likely, since that defeats one 
>> of the main pieces of what makes a struct a struct. So I’m all for this 
>> proposal of allowing type aliases to be extended as though they were their 
>> own struct/class.
>> 
>> Unfortunately, I’m not sure how feasible this kind of functionality would 
>> actually be, but if it’s possible then I’m in favor of implementing it.
>> 
>>> On Jun 8, 2017, at 10:14 PM, Yvo van Beek via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Typealiases can greatly reduce the complexity of code. But I think one 
>>> change in how the compiler handles them could make them even more powerful.
>>> 
>>> Let's say I'm creating a web server framework and I've created a simple 
>>> dictionary to store HTTP headers (I know that headers are more complex than 
>>> that, but as an example). I could write something like this:
>>> 
>>> typealias HeaderKey = String
>>> 
>>>   var headers = [HeaderKey: String]()
>>>   headers["Host"] = "domain.com <http://domain.com/>"
>>> 
>>> Now I can define a couple of default headers like this:
>>> 
>>>   extension HeaderKey {
>>> static var lastModified: String { return "Last-Modified" }
>>> static var host: String { return "Host" }
>>>   }
>>> 
>>> After that I can do this:
>>> 
>>>   var headers = [HeaderKey: String]()
>>>   headers[.host] = "domain.com <http://domain.com/>"
>>>   headers[.lastModified] = "some date"
>>>   headers["X-MyHeader"] = "This still works too"
>>> 
>>> But unfortunately the extension is also applied to normal strings:
>>> 
>>> var normalString: String = .host
>>> 
>>> Perhaps it would be better if the extension would only apply to the parts 
>>> of my code where I use the HeaderKey typealias and not to all Strings. This 
>>> could be a great tool to specialize classes by creating a typealias and 
>>> adding functionality to it. Another example I can think of is typealiases 
>>> for dictionaries or arrays wi

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

[Jacob Williams via swift-evolution]

+1 from me.

There have been times I’ve wanted to subclass an object (such as String) but 
since it is a non-class, non-protocol type you can only extend Strings existing 
functionality which adds that same functionality to Strings everywhere. It 
would be nice if we could either extend type aliases (and only the type alias), 
or if it were possible to inherit from structs so that we could create a custom 
string type like so:

struct HeaderKey: String {
static var lastModified: String { return “Last-Modified” }
static var host: String { return “Host” }
}

I realize that struct inheritance is far less likely, since that defeats one of 
the main pieces of what makes a struct a struct. So I’m all for this proposal 
of allowing type aliases to be extended as though they were their own 
struct/class.

Unfortunately, I’m not sure how feasible this kind of functionality would 
actually be, but if it’s possible then I’m in favor of implementing it.

> On Jun 8, 2017, at 10:14 PM, Yvo van Beek via swift-evolution 
>  wrote:
> 
> Typealiases can greatly reduce the complexity of code. But I think one change 
> in how the compiler handles them could make them even more powerful.
> 
> Let's say I'm creating a web server framework and I've created a simple 
> dictionary to store HTTP headers (I know that headers are more complex than 
> that, but as an example). I could write something like this:
> 
> typealias HeaderKey = String
> 
>   var headers = [HeaderKey: String]()
>   headers["Host"] = "domain.com "
> 
> Now I can define a couple of default headers like this:
> 
>   extension HeaderKey {
> static var lastModified: String { return "Last-Modified" }
> static var host: String { return "Host" }
>   }
> 
> After that I can do this:
> 
>   var headers = [HeaderKey: String]()
>   headers[.host] = "domain.com "
>   headers[.lastModified] = "some date"
>   headers["X-MyHeader"] = "This still works too"
> 
> But unfortunately the extension is also applied to normal strings:
> 
> var normalString: String = .host
> 
> Perhaps it would be better if the extension would only apply to the parts of 
> my code where I use the HeaderKey typealias and not to all Strings. This 
> could be a great tool to specialize classes by creating a typealias and 
> adding functionality to it. Another example I can think of is typealiases for 
> dictionaries or arrays with added business logic through extensions 
> (especially since you can't inherit from structs).
> 
> If you want to create an extension that adds functionality to all Strings you 
> could have created an extension for String instead of HeaderKey.
> 
> Please let me know what you think. I'm not sure how complex this change would 
> be.
> I could write a proposal if you're interested.
> 
> Kind regards,
> Yvo
> ___
> 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] Localized Swift Frameworks

[Jacob Williams via swift-evolution]

+1

While I think this could be an incredibly useful feature that would make 
teaching coding to people much easier since they no longer need to learn 
English words at all, I think this can get really tricky when you consider 
autocomplete and all of the work an IDE has to do to identify the language then 
get the localized string and suggest that to the user. The huge amounts of 
words/verbs/functions/variables that would have to be dynamically localized 
could really slow down an IDE. And Xcode already has a hard enough time 
handling everything right now...

> On Mar 24, 2017, at 12:33 PM, Jeff Kelley via swift-evolution 
>  wrote:
> 
> I think one of the easiest ways to do it would be to ensure that the actual 
> .swift files are all using the root language of the framework—akin to the 
> development region of an app. Using metadata the IDE would dynamically 
> substitute the localized names, but the underlying file would use the 
> canonical values. Trying to store the localized code in the files makes using 
> version control across language borders impossible.
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com  | @SlaunchaMan 
>  | jeffkelley.org 
>> On Mar 24, 2017, at 2:03 PM, Joshua Alvarado > > wrote:
>> 
>> I wonder what it would do for reusability. It would be hard to share code 
>> between countries written in Spanish or japanense unless the compiler could 
>> convert the code to your language. Maybe properties and function calls could 
>> be converted over to different languages but I am not sure Swift keywords 
>> could be as easily converted which could lead to code with mixed languages 
>> due to languages not mapping 1 to 1 on every word. This would be really cool 
>> but a LOT of work. I think this is a bigger issue than just adding it into 
>> Swift. Taking a look at non-English-based programming languages - 
>> https://en.wikipedia.org/wiki/Non-English-based_programming_languages 
>>  - 
>> there are very few, if any, highly used languages on the list. Some 
>> languages implemented symbols instead of words so that it is not language 
>> based but that would cause breaking changes in Swift :)
>> 
>> It would be cool to see code in different languages:
>> 
>> for i in foo {
>>print(i)
>> }
>> 
>> para i en foo {
>>escribir(i)
>> }
>> 
>> On Fri, Mar 24, 2017 at 11:28 AM, Jeff Kelley via swift-evolution 
>> > wrote:
>> One of the things that struck me from today’s Apple press release about 
>> Swift Playgrounds being localized in more languages is this screenshot:
>> 
>> 
>> 
>> All of the UI is fully localized for Chinese, except the actual code. As far 
>> as I know, almost every major programming language and major platform 
>> framework is primarily English; it’s become the de facto language for 
>> developers. But does that have to be the case?
>> 
>> Imagine a world where alongside our Swift frameworks, we ship .strings files 
>> that contain translations of our APIs to other languages. From some other 
>> screenshots we see that Swift Playgrounds is providing translations of 
>> method names to explain them, here providing “avanzar” for “moveForward()”.
>> 
>> 
>> 
>> A scenario where Swift supported localized frameworks might see a .strings 
>> file with a format like this:
>> 
>> "moveForward()": "avanzar()"
>> 
>> Then, in Swift code, whether through an IDE, some metadata in a comment in 
>> the Swift file, or file extension (think “Foo.es .swift”), a 
>> developer who selects Spanish could simply write avanzar() and understand it 
>> in her native language. In fact, if the IDE is the layer that handles 
>> language selection, two developers who don’t even speak the same language 
>> could collaborate on code, and names from the framework would appear to each 
>> in their native language!
>> 
>> Comments and locally-defined names are of course still a barrier, but this 
>> isn’t new. I know that “mazu” means “first” in Japanese thanks to some code 
>> I worked on with an old coworker.
>> 
>> This is obviously out of scope for Swift 4, and would require significant 
>> effort to support, both technically in Swift itself and for those shipping 
>> Swift frameworks, both inside and outside of Apple, to provided localized 
>> names, so I wanted to throw this out to see if the community is even 
>> interested.
>> 
>> There’s just something about the idea of kids all over the world using Swift 
>> Playgrounds completely in their own language that makes me think this could 
>> help Swift achieve its stated goal of world dominance.
>> 
>> 
>> Jeff Kelley
>> 
>> slauncha...@gmail.com  | @SlaunchaMan 
>>