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

[Lukas Stabe via swift-evolution]

I'd love to see `if value matches pattern`. Every time I use `if case` I have 
to stop and think to remember the weird syntax. I get where it came from, but I 
think `matches` better describes what happens here (one is immediately reminded 
of pattern matching).

I don't know wether this might be unfeasible to do due to compiler performance 
limitations, but I would support a proposal to replace `if case` with `if value 
matches pattern`. 

An alternative may be to introduce a custom operator that just calls `~=` with 
the arguments reversed, but imho this should rather be fixed at the language 
level.

– Lukas

> On 26 Mar 2016, at 18:13, Erica Sadun via swift-users  
> wrote:
> 
>> On Mar 26, 2016, at 3:47 PM, Maury Markowitz via swift-users 
>>  wrote:
>> 
>> Before I stick my head into the other list, consider:
>> 
>>   if statusCode >= 200 && statusCode <= 299
>> 
>> I'm sure examples of something like this occur throughout your code. But the 
>> actual semantics of the test is hidden here, you're really testing if 
>> statusCode lies within a range. Swift 2.0 has a couple of options for this, 
>> but I find them all rather odd. The most recommended is:
>> 
>>   if case 0...100 = someInteger
> 
> While I prefer: 
> 
> if 200...299 ~= statusCode { print("within 200-299") }
> 
> I see that you're asking specifically about case/=. But keep that example in 
> mind because I'm
> going to circle back to it.
> 
>> This syntax has problems. For one thing, it's written backwards compared to 
>> most people's code...
>> 
>>   if someinteger == 100
>> 
>> not...
>> 
>>   if 100 == someinteger
>> 
>> so it just *feels* wrong. In addition, the use of "case" seems odd too. And 
>> finally, there's the use of the single equals sign in a test, which goes 
>> against everything we've learned in C-like languages.
>> 
>> So unless I'm missing something, can anyone offer a reason this wouldn't 
>> work?
>> 
>>  if someinteger in 0...100
> 
> This is a built-in problem with "if case/=". Starting with the core statement 
> :
> 
> if case pattern = value {...}
> 
> It's far easier to read and understand the equivalent switch than the 
> one-liner:
> 
> switch (value) {
> case pattern: ...
> default: break
> }
> 
> Once you convert to a switch, the "If this value can be matched to this 
> pattern" 
> becomes a lot less mentally weird but there's also a lot of extra fluff that 
> if case
> attempts to trim away. Here's a concrete example.  "In the case that the 
> pattern 
> Test.A(Int) can be matched to this value then bind x to the associated Int 
> value"
> 
> let value = Test.A(23)
> 
> if case Test.A(let x) = value {
> print(x) // will print 23
> }
> 
> Again the switch is a lot more intuitive to read, but contains a lot of 
> unneeded
> details that can and should be trimmable:
> 
> switch (value) {
> case Test.A(let x): ...
> default: break
> }
> 
> And here's the oddest example of this Case/= construct I can think of in terms
> of the "read through" not matching the actual programming intent of "In the 
> case that the array indices can be matched to this value" 
> 
> if case array.indices = array.startIndex { print("strange but yup") }
> 
> And its switch equivalent, which is way more obvious in terms of intent:
> 
> switch (array.startIndex) {
> case array.indices: ...
> default: break
> }
> 
> Now back to your original point. Could this be expressed better? For sure. I 
> think these are far more readable:
> 
> if value in range {...} // vs if range ~=
> if value matches pattern {...} // vs if case pattern = value
> 
> And for these specific examples, they'd look like this in an updated Swift 
> that adopted these changes:
> 
> if statusCode in 200...299 { print("within 200-299") }
> if value matches Test.A(let x) { print(x) } // will print 23
> if array.startIndex in array.indices { print("the ~= variation") }
> if array.startIndex matches array.indices { print ("better example Case/=") }
> 
> That said, I've also made my opinion clear over there that the use of "let" 
> and "var"
> in "if let" unnecessarily overloads constant and variable binding (it's 
> testing something 
> that actually acts differently than the standalone let due to unwrapping). 
> This got nowhere
> for a variety of compelling and less compelling reasons. (I'd prefer "if 
> bind" even if it  
> sacrifices a variable variant.)
> 
> I certainly think it's worth doing at least a [Pitch] over in -evolution with 
> the alternate 
> constructs.
> 
> -- E
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Mar 26, 2016, at 3:47 PM, Maury Markowitz via swift-users 
>  wrote:
> 
> Before I stick my head into the other list, consider:
> 
>   if statusCode >= 200 && statusCode <= 299
> 
> I'm sure examples of something like this occur throughout your code. But the 
> actual semantics of the test is hidden here, you're really testing if 
> statusCode lies within a range. Swift 2.0 has a couple of options for this, 
> but I find them all rather odd. The most recommended is:
> 
>   if case 0...100 = someInteger

While I prefer: 

if 200...299 ~= statusCode { print("within 200-299") }

I see that you're asking specifically about case/=. But keep that example in 
mind because I'm
going to circle back to it.

> This syntax has problems. For one thing, it's written backwards compared to 
> most people's code...
> 
>   if someinteger == 100
> 
> not...
> 
>   if 100 == someinteger
> 
> so it just *feels* wrong. In addition, the use of "case" seems odd too. And 
> finally, there's the use of the single equals sign in a test, which goes 
> against everything we've learned in C-like languages.
> 
> So unless I'm missing something, can anyone offer a reason this wouldn't work?
> 
>  if someinteger in 0...100

This is a built-in problem with "if case/=". Starting with the core statement :

if case pattern = value {...}

It's far easier to read and understand the equivalent switch than the one-liner:

switch (value) {
case pattern: ...
default: break
}

Once you convert to a switch, the "If this value can be matched to this 
pattern" 
becomes a lot less mentally weird but there's also a lot of extra fluff that if 
case
attempts to trim away. Here's a concrete example.  "In the case that the 
pattern 
Test.A(Int) can be matched to this value then bind x to the associated Int 
value"

let value = Test.A(23)

if case Test.A(let x) = value {
print(x) // will print 23
}

Again the switch is a lot more intuitive to read, but contains a lot of unneeded
details that can and should be trimmable:

switch (value) {
case Test.A(let x): ...
default: break
}

And here's the oddest example of this Case/= construct I can think of in terms
of the "read through" not matching the actual programming intent of "In the 
case that the array indices can be matched to this value" 

if case array.indices = array.startIndex { print("strange but yup") }

And its switch equivalent, which is way more obvious in terms of intent:

switch (array.startIndex) {
case array.indices: ...
default: break
}

Now back to your original point. Could this be expressed better? For sure. I 
think these are far more readable:

if value in range {...} // vs if range ~=
if value matches pattern {...} // vs if case pattern = value

And for these specific examples, they'd look like this in an updated Swift that 
adopted these changes:

if statusCode in 200...299 { print("within 200-299") }
if value matches Test.A(let x) { print(x) } // will print 23
if array.startIndex in array.indices { print("the ~= variation") }
if array.startIndex matches array.indices { print ("better example Case/=") }

That said, I've also made my opinion clear over there that the use of "let" and 
"var"
in "if let" unnecessarily overloads constant and variable binding (it's testing 
something 
that actually acts differently than the standalone let due to unwrapping). This 
got nowhere
for a variety of compelling and less compelling reasons. (I'd prefer "if bind" 
even if it  
sacrifices a variable variant.)

I certainly think it's worth doing at least a [Pitch] over in -evolution with 
the alternate 
constructs.

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

Re: [swift-evolution] Rewrite imported C function signatures

[Brent Royal-Gordon via swift-evolution]

>> What's wrong with just overloading it like this without hiding the original? 
>> That way you can start by directly porting (perhaps even mechanically 
>> converting) the code and later refine it to use the nicer Swift-style 
>> overload.
> 
> Well, the difference is that the compiler could produce a warning or error 
> with fixit to indicate the developer that an alternative signature to the 
> originally C imported one is available. This way, code ports should gain much 
> readability, while not requiring much effort from the developer to make use 
> of the newer signature.

If that's all you want, maybe we can have an attribute which says "prefer this 
version over that one":

@preferred(since: 3.0, over: socket(_: Int32, _: Int32, _: Int32) -> 
Int32)
func socket(domain:SocketDomain, type:SocketType, 
protocol:SocketProtocol) -> socket_t? {
let result = socket(domain.rawValue, type.rawValue, 
protocol.rawValue)
if result == -1 {
return nil
}
else{
return result
}
}

This would effectively apply an `@available(deprecated: 3.0, renamed: 
socket(domain: SocketDomain, type: SocketType, protocol: SocketProtocol) -> 
socket_t?)` to the other API.

(Or, for that matter, you could simply use an API note to apply that 
deprecation to the other API, which would not require any new features.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

[Ankit Agarwal via swift-evolution]

>
> It is a convention to name the .pc file after the library link-name, so
> we can determine which .pc file to ask pkg-config for by parsing the
> .modulemap file in the Swift package.


what about the cases where .pc file doesn't matches the link-name from
modulemap for eg : gtk+2 or 3 has these link-names: `link "gtk-2.0"`, `link
"gtk-3.0"` and .pc files are `gtk+-2.0.pc`, `gtk+-3.0.pc`

One option could be an optional in Package -> `pkgconfig: "gtk+-2.0"`



Probably not in scope of this proposal, I noticed that pkg-config can give
versions of the system libs, would it be a good idea for user to mention a
version range of system lib while creating the modulemap wrapper package.



On Wed, Mar 23, 2016 at 11:40 PM, Max Howell via swift-evolution <
swift-evolution@swift.org> wrote:

> SwiftPM System Module Search Paths
>
>- Proposal: SE-
>
> 
>- Author: Max Howell 
>- Status: Awaiting review
>- Review manager: Anders Bertelrud
>
> Introduction
>
> Swift is able to import C libraries in the same manner as Swift libraries.
>
> For this to occur the library must be represented by a clang module-map
> file.
>
> The current system for using these module-map files with SwiftPM works,
> but with a number of caveats that must be addressed.
> Motivation
>
> The current implementation of system module packages have a number of
> problems:
>
>1. Install locations vary across platforms and modulemap files require
>absolute paths
>2. /usr/lib:/usr/local/lib is not always a sufficient -L search path
>3. /usr/include:/usr/local/include is not always a sufficient -I C
>compiler search path
>4. Installing the system library is left up to the end-user to figure
>out
>
> For example to import a module map representing the GTK library, the
> include search path must be supplemented with -I/usr/include/gtk so that
> a number of includes in the gtk.h header can be sourced for the complete
> modular definition of GTK.
>
> For example to import a module map representing the GTK library a user
> must first have a copy of GTK and its headers installed. On Debian based
> systems the install name for this system package is libgtk-3-0-dev which
> is not entirely intuitive.
>
> For example, Homebrew and MacPorts on OS X install to prefixes other than
> /usr..modulemap files must specify headers with absolute paths. The
> standard we encourage with modulemaps is for the headers to be specified
> with an assumed prefix of /usr, but you will not find eg. jpeglib.h at
> /usr/include/jpeglib.h if it is installed with Homebrew or MacPorts.
> Proposed Solution
>
> We propose that SwiftPM gains the ability to use the cross-platform
> pkg-config tool so that it can query pkg-config for the missing path and
> flag arguments.
>
> We propose that SwiftPM gains the ability to use the cross-platform
> pkg-config tool to identify when the system package is not installed to a
> /usr and in such a case preprocess the modulemap changing the prefix it
> uses.
>
> We propose that Package.swift is supplemented with metadata that provides
> the package-install-name for specific platforms.
> Detailed DesignSolving Path/Flags Issues
>
> Some of our problems can be solved by using the cross platform tool:
> pkg-config.
>
> A C package can provide a pkg-config file (.pc) which describes:
>
>1. Its install location
>2. Supplementary C-flags that should be used when building against
>this library
>
> If SwiftPM used the .pc file that comes with packages, this solves
> problems 1 through 3.
>
> Of the tickets we currently have open describing issues using
> Swift-system-module-packages, reading the .pc file would fix all of them.
>
> It is a convention to name the .pc file after the library link-name, so
> we can determine which .pc file to ask pkg-config for by parsing the
> .modulemap file in the Swift package.
> Providing Package Install Names
>
> Package.swift would be supplemented like so:
>
> let package = Package(
> name: "CFoo",
> providers: .Brew(installName: "foo"),
> .Apt(installName: "libfoo-dev"),
> )
>
> Thus, in the event of build failure for modules that depend on this
> package we provide additional help to the user:
>
> error: failed to build module `bar'
> note: you may need to install `foo' using your system-packager:
>
> apt-get install libfoo-dev
>
> Since the syntax to provide this information uses an explicit enum we can
> add code for each enum to detect which system packagers should be
> recommended. The community will need to write the code for their own
> platforms. It also means that if a specific packager requires additional
> parameters, they can be added on a per enum basis.
> Impact on Existing Code
>
> There will be no impact on existing code as this feature simply improves
> an existing feature making n

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Patrick Gili via swift-evolution]

> 
>   * What is your evaluation of the proposal?

The IUO is not a transitional technology, as it is essential to bridge from 
languages from which Swift evolved, such as C and Objective-C. The proposal 
doesn't give much consideration to this application of IUOs, and hence, I 
cannot support the proposal in its current state.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Grant it, the use of IUO outside of bridging is strange and probably a poor 
practice. However, there seems to exist a requirement and this proposal would 
make satisfying this requirement more difficult.

>   * Does this proposal fit well with the feel and direction of Swift?

No.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Not applicable.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

In-depth study.

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

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

[Patrick Gili via swift-evolution]

> What is your evaluation of the proposal?
+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes.

> Does this proposal fit well with the feel and direction of Swift?

Yes.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I have not used a language with a similar feature.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Read thoroughly.


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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

[Patrick Gili via swift-evolution]

> 
> 
>   * What is your evaluation of the proposal?

Given var has been removed and inout has been moved, forcing developers to 
specify let seems redundant, and hence I support the proposal.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Redundancy is as bad as inconsistency. Hence, the problem is significant enough 
to warrant a change.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Not really.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick read.


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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Haravikk via swift-evolution]

> On 26 Mar 2016, at 14:11, Ross O'Brien  wrote:
> 
> Haravikk: private (type) would be the subject of another proposal.
> 
> What this proposal is about is the following (all in one file):
> 
> struct Foo {
> func doThing() {
> doPrivateThing()
> }
> 
> private func doPrivateThing() { }
> }
> 
> extension Foo {
> func doOtherThing() {
> doPrivateThing()
> }
> 
> private func doPrivateThing() { }
> }
> 
> There would be two functions called doPrivateThing(). The first is private to 
> the struct declaration; the second to the extension. There's no conflict 
> between them.

I wasn’t actually trying to propose a new form of visibility, but the keyword 
discussion keeps coming up on various types of visibility so I guess I’m just 
getting confused with my terminology in these cases. My point was to re-raise 
the private(foo) style rather than cover some other type of visibility. It also 
doesn’t help that everyone has different names on what everything should named, 
but then that’s partly the point I was trying to make =D

> The reason we continue to have confusion about this (I'm guilty of this too) 
> is because "private" has a standard meaning in many languages and a 
> non-standard meaning in Swift.
> 
> Chris Lattner's explained the reasoning about conjoined keywords in a few 
> places I think, but the posts from this thread are here:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html
>  
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013439.html
>  
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013463.html
>  
> 
Thanks for linking these, but I really don’t like any of the proposed conjoined 
keywords any more than I like the suggested single-word alternatives, which is 
why I really feel that the parenthesised restriction is a much better style, as 
we can argue forever on what the best new visibility keywords and nothing will 
be good enough IMO. The parenthesised style however means that we not only 
avoid keyword bloat, we would actually remove one, plus we get the same benefit 
to clarity of having two-word visibility without the nastiness of the various 
conjoined options I’ve seen so far.

Other than it being “weird and awkward” I don’t see any real reasons why we 
can’t just the private(foo) style; it’s not really more awkward than a 
conjoined keyword, and I think that the logical grouping is worth it being a 
bit different. In fact, in the first linked post Chris points out that well 
chosen public/private defaults should be all that most people need, so you only 
need the parenthesis for the more unusual cases which I think makes it ideal.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jose Cheyo Jimenez via swift-evolution]

+1 for this. The only reason I was thinking 'external' was because 'module' 
seems to clash with the identity of the actual module but i am for the order 
and introducing a new word for module access. 


> On Mar 14, 2016, at 7:38 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> I, too, prefer it to be more like this:
> 
> public  // unchanged
> module  // currently internal
> internal  // currently private
> private  // new hotness
> 
> l8r
> Sean
> 
> 
>> On Mar 14, 2016, at 7:50 PM, Jo Albright via swift-evolution 
>>  wrote:
>> 
>> +1
>> 
>> I like this a lot. Name ideas : enclosed, filelocal, fileonly, filelock, 
>> fileaccess, fileprivate, insidefile, inner. I also like Erica’s filebound & 
>> file fixed.
>> 
>> By Erica’s suggestion about switching…
>> 
>> - public
>> - modular, modulelock, packaged  (module only)
>> - internal (file only)
>> - private
>> 
>> Designer . Developer .  Nerd 
>> Jo Albright
>> 
>> 
>>> On Mar 14, 2016, at 8:18 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> Per Doug’s email, the core team agrees we should make a change here, but 
>>> would like some bikeshedding to happen on the replacement name for private.
>>> 
>>> To summarize the place we’d like to end up:
>>> 
>>> - “public” -> symbol visible outside the current module.
>>> - “internal” -> symbol visible within the current module.
>>> - unknown -> symbol visible within the current file.
>>> - “private” -> symbol visible within the current declaration (class, 
>>> extension, etc).
>>> 
>>> The rationale here is that this aligns Swift with common art seen in other 
>>> languages, and that many people using private today don’t *want* visibility 
>>> out of their current declaration.  It also encourages “extension oriented 
>>> programming”, at least it will when some of the other restrictions on 
>>> extensions are lifted.  We discussed dropping the third one entirely, but 
>>> think it *is* a useful and important level of access control, and when/if 
>>> we ever get the ability to write unit tests inside of the file that defines 
>>> the functionality, they will be a nicer solution to @testable.
>>> 
>>> The thing we need to know is what the spelling should be for the third one. 
>>>  Off hand, perhaps:
>>> 
>>> fileprivate
>>> private(file)
>>> internal(file)
>>> fileaccessible
>>> etc
>>> 
>>> Some other thoughts on the choice: 
>>> - this will be a declaration modifier, so it will not “burn” a keyword.
>>> - if will be a uniquely Swift thing, so there is virtue in it being a 
>>> googlable keyword.
>>> 
>>> Thoughts appreciated.
>>> 
>>> -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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jose Cheyo Jimenez via swift-evolution]

The word 'external' is growing on me but as the (module access). 

public (unchanged)
external (module access)
internal (file access)
private (scoped access)

module access = has external access from other files in the module. 
file access = has internal access to current file
scope access = has only access to the current scope. 

Private will align with other languages definition of private. 
I don't think public should change and I don't like all the others to be called 
private(levelofprivacy).




> On Mar 25, 2016, at 7:32 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> I'll throw another suggestion into the ring:
> 
> private (scoped access)
> public (file access)
> internal (module access)
> external (infinity and beyond)
> 
> l8r
> Sean
> 
> Sent from my iPad
> 
>> On Mar 25, 2016, at 8:57 PM, Ross O'Brien via swift-evolution 
>>  wrote:
>> 
>> The specific meaning of 'public' and 'private' in programming languages 
>> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and 
>> Objective C; their 'public' is Swift's 'internal'. They have no equivalent 
>> to Swift's 'public'. Swift has no equivalent to their 'private'.
>> 
>> Possibly my familiarity with other languages isn't broad enough, but this is 
>> why I haven't understood the idea that Swift's use of 'private' is "right" 
>> or "obvious". You learn Swift's meanings of these terms by coding in Swift, 
>> you don't learn these meanings anywhere else first.
>> 
>> To use a hopefully recognised example: an American who wants 'chips' wants 
>> what a Brit calls crisps; a Brit who wants chips wants what an American 
>> calls french fries. Which meaning of 'chips' is more intuitive? Answer: the 
>> one you grew up with.
>> 
>>> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> > all of these names (public, internal, private, local) have specific 
>>> > meaning in the context of computer languages.
>>> 
>>> Yes, `local` has a meaning, but that meaning is generally *not* that it's 
>>> an access level. It usually has something to do with declaring variables 
>>> inside a function.
>>> 
>>> For instance, Perl uses it to back up and restore a global variable. ML 
>>> uses it to create a scope (roughly). Lua and Julia use it to declare 
>>> lexical variables which are visible in enclosed scopes, which SE-0025's new 
>>> access level is specifically *not* supposed to allow.
>>> 
>>> I don't know of any language where `local` is used as an access level. If 
>>> you're aware of an analogous use in another language, I'd be interested to 
>>> see it. But the examples I've found if anything *undermine* the suggestion 
>>> that `local` would be a good keyword choice.
>>> 
>>> --
>>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

[Антон Жилин via swift-evolution]

UnsafePointer is most often used for interfacing with C libraries. They
will almost never add nullability annotations. It means that
UnsafePointer? will become an idiom. But we currently have a terser
form, and it's arguably clear from it that Pointer can be null.

90% of programmers and 99.9% of those working with C libraries are familiar
with concept of C pointer and null pointer. So it's clear for every one we
can call a programmer that *Pointer types contain plain C nullable pointers
with Swift whistles.

Overall, separating strongly connected concepts and then tying them
together using compiler magic just can't have a reasonable explanation.
~0x0 in UnsafeBufferPointer is utterly rediculous.

> What is your evaluation of the proposal?
-1

> Is the problem being addressed significant enough to warrant a change to
Swift?
No, I don't see any motivation for the change.

> Does this proposal fit well with the feel and direction of Swift?
No, it's headed in the opposite direction.

> If you have you used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
Rust denotes pointers using * and has no problems with that.

> How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
Followed the discussion.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Антон Жилин via swift-evolution]

First of all, -1 for still not exposing @autounwrapped to the user as
discussed.
But there is a greater problem.

If we move from current type syntax to attribute syntax, we should remove
T!, because it can no longer be a type. Otherwise we will only bring more
inconsistency into the language.

But then you'll say @autounwrapped is too verbose to be used everywhere.

Let's be honest, we rarely use IUO in Swift (IBoutlet was noted).
Objective-C does not use T! syntax. So the goal is actually to reduce
syntactic noise in documentation of imported functions.

One solution could be to remove T! from Swift, but leave this notation for
documentation. Or brainstorm that and find another terse and readable
syntax.

> What is your evaluation of the proposal?
Right now, -2.

> Is the problem being addressed significant enough to warrant a change to
Swift?
Yes, compiler magic should be limited.

> Does this proposal fit well with the feel and direction of Swift?
Idea - yes, wording - no.

> If you have you used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
No languages that I know of have IUO.

> How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
Followed and participated in the discussion.

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien via swift-evolution]

Haravikk: private (type) would be the subject of another proposal.

What this proposal is about is the following (all in one file):

struct Foo {
func doThing() {
doPrivateThing()
}

private func doPrivateThing() { }
}

extension Foo {
func doOtherThing() {
doPrivateThing()
}

private func doPrivateThing() { }
}

There would be two functions called doPrivateThing(). The first is private
to the struct declaration; the second to the extension. There's no conflict
between them.

What you suggest would be a proposal of its own - it would have to be,
because types can be extended outside of their original modules, which
would beg the question of whether a property could actually be a 'public
(type)' rather than a 'private (type)'.

The reason we continue to have confusion about this (I'm guilty of this
too) is because "private" has a standard meaning in many languages and a
non-standard meaning in Swift.

Chris Lattner's explained the reasoning about conjoined keywords in a few
places I think, but the posts from this thread are here:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013439.html
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013463.html


On Sat, Mar 26, 2016 at 9:13 AM, Haravikk 
wrote:

> I can’t find a reply that seemed to cover this so I’d like to ask again,
> but why just you a parameter on private for all hidden visibility types?
> i.e-
>
> public (current meaning of public)
> private (module) (current meaning of internal)
> private (type) (new scoped visibility, could be named scoped instead but
> I prefer type personally)
> private (file) (current meaning of private)
>
> This eliminates the need for an additional keyword, and actually trims
> internal as well, plus all visibility is then either public (externally
> accessible) or private (internally accessible with some degree of
> restriction). When used without a parameter private on its own would now
> default to private (type).
>
> The ability to place a visibility restriction only upon a getter/setter
> would be handled as a parameter value, for example:
>
> private (file: set) (value can only be set within this file)
> private (type: get, file: set) (value is accessible within type,
> sub-types and extensions, but can only be set within this file)
>
> I think it’s a very neat way to do things, and I think that for most cases
> private (type), the new default for private, is sufficient for a lot of
> use-cases. More importantly it eliminates the need for new keywords,
> actually trims one (we only need two for visibility not four) and also
> eliminates the need to find good single-word keywords that make sense on
> their own, since all limited types are explicitly grouped as private which
> should make it absolutely clear.
>
> On 26 Mar 2016, at 07:14, Cheyo Ximenez via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree with Ross. Swift already redefined the common access modifiers
> meanings.
> Why not use the word 'protected' to mean 'local'?
>
> public
> internal
> private
> protected // Java got it wrong. :) This is "protected" against extensions.
>
>
> On Mar 25, 2016, at 6:57 PM, Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The specific meaning of 'public' and 'private' in programming languages
> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and
> Objective C; their 'public' is Swift's 'internal'. They have no equivalent
> to Swift's 'public'. Swift has no equivalent to their 'private'.
>
> Possibly my familiarity with other languages isn't broad enough, but this
> is why I haven't understood the idea that Swift's use of 'private' is
> "right" or "obvious". You learn Swift's meanings of these terms by coding
> in Swift, you don't learn these meanings anywhere else first.
>
> To use a hopefully recognised example: an American who wants 'chips' wants
> what a Brit calls crisps; a Brit who wants chips wants what an American
> calls french fries. Which meaning of 'chips' is more intuitive? Answer: the
> one you grew up with.
>
> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > all of these names (public, internal, private, local) have specific
>> meaning in the context of computer languages.
>>
>> Yes, `local` has a meaning, but that meaning is generally *not* that it's
>> an access level. It usually has something to do with declaring variables
>> inside a function.
>>
>> For instance, Perl uses it to back up and restore a global variable. ML
>> uses it to create a scope (roughly). Lua and Julia use it to declare
>> lexical variables which are visible in enclosed scopes, which SE-0025's new
>> access level is specifically *not* supposed to allow.
>>
>> I don't know of any language where `local` is used as an access level. If
>> you

[swift-evolution] Rewrite imported C function signatures

[Carlos Rodríguez Domínguez via swift-evolution]

I’ve been rethinking the proposal and maybe a more suitable syntax should be:

#override(socket(_:,_:,_:)->Int32)
func socket(domain:SocketDomain, type:SocketType, protocol:SocketProtocol) -> 
socket_t? {
//…
}

In this way it is clearer that the idea is to bring func overriding to global 
functions.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[James Campbell via swift-evolution]

* What is your evaluation of the proposal?
I think this is a positive step in the right direction but I think there still 
needs to be more amendments. So a +1 if address the issues I'm about to outline.
Anything not annotated should be imported as an optional not a IUO, this makes 
it safer to handle the nil case with legacy code. 
This is also truer to the intent of the original objective c code.
The proposal so far agrees with this, however there is one part I think could 
make clearer.
This:
Let x: Int! = 5Let y = x 
It's not clear to me that y would be converted to an optional or that it would 
crash if it couldn't be type converted. This is a huge departure from the 
existing swift.
I think it would be better to have what I call Optional Type Confermence.
If I want y to be a Int! I can refer to x with a ! :
Let x:Int! = 5Let y = x!
That way if x is nil the app will trap and this provides a path for existing 
code to still use this behaviour plus it's now obvious that x will be treated 
like an unwrapped optional.
If you wanted x to be treated like an optional you would use ? 
Let x: Int! = 5Let y = x?
This would make the behaviour the proposal is proposing much clearer.   * Is 
the problem being addressed significant enough to warrant a change to 
Swift?Although the proposal doesn't outline a problem, I do believe the 
optional system in swift today isn't safe enough. Indeed I released an app that 
crashed due to swift importing an unannotated piece of objective c code that 
wasn't clear about how it was an IUO and crashed.Anything that improves this 
visibility of IUOs and reduces the need of them I am for.
* Does this proposal fit well with the feel and direction of Swift?This 
fits with Swift 3s simplification of the APIs   * If you have you used other 
languages or libraries with a similar feature, how do you feel that this 
proposal compares to those?I don't have any experience in other languages.  
  * How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

In depth study.

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager



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



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

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Bernd Ohr (jazzbox) via swift-evolution]

> * What is your evaluation of the proposal?

I don’t like the proposal.

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

I don't agree that IUOs are a transitional technology as long as there is an 
import of C libraries.

The only problem I see that IUO’s are being used where it is not necessary, 
either out of ignorance or convenience.

My counter proposal: IUO’s are only allowed (in pure Swift files) with private 
scope (filePrivate) and not with internal or public scope! In this way the 
uncontrolled spread of IUO’s can be most easily prevented.

An additional restriction could be that IUO’s are only allowed in files that 
import C or ObjC libraries.

> * Does this proposal fit well with the feel and direction of Swift?

No, because it makes the use of IUO’s much harder (IMHO) where it is really 
necessary.

> * If you have you used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

N/A

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

I read the proposal and had a look at some of my code that uses IUO’s 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Rewrite imported C function signatures

[Carlos Rodriguez Dominguez via swift-evolution]

Well, the difference is that the compiler could produce a warning or error with 
fixit to indicate the developer that an alternative signature to the originally 
C imported one is available. This way, code ports should gain much readability, 
while not requiring much effort from the developer to make use of the newer 
signature.

El 26 mar 2016, a las 5:53, Brent Royal-Gordon  
escribió:

>> As you can observe, that old-style signature is highly error prone, does not 
>> comply with swift guidelines, it is difficult to understand, etc. My opinion 
>> is that there should be some syntax to rewrite the signature to avoid those 
>> issues. For instance, a possible syntax could be:
>> 
>> #mapsignature(socket(_:,_:,_:)->Int32)
>> func socket(domain:SocketDomain, type:SocketType, protocol:SocketProtocol) 
>> -> socket_t? {
>>let result = socket(domain.rawValue, type.rawValue, protocol.rawValue)
>>if result == -1 {
>>return nil
>>}
>>else{
>>return result
>>}
>> }
> 
> What's wrong with just overloading it like this without hiding the original? 
> That way you can start by directly porting (perhaps even mechanically 
> converting) the code and later refine it to use the nicer Swift-style 
> overload.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Haravikk via swift-evolution]

I can’t find a reply that seemed to cover this so I’d like to ask again, but 
why just you a parameter on private for all hidden visibility types? i.e-

public  (current meaning of public)
private (module)(current meaning of internal)
private (type)  (new scoped visibility, could be named scoped 
instead but I prefer type personally)
private (file)  (current meaning of private)

This eliminates the need for an additional keyword, and actually trims internal 
as well, plus all visibility is then either public (externally accessible) or 
private (internally accessible with some degree of restriction). When used 
without a parameter private on its own would now default to private (type).

The ability to place a visibility restriction only upon a getter/setter would 
be handled as a parameter value, for example:

private (file: set) (value can only be set within 
this file)
private (type: get, file: set)  (value is accessible within type, 
sub-types and extensions, but can only be set within this file)

I think it’s a very neat way to do things, and I think that for most cases 
private (type), the new default for private, is sufficient for a lot of 
use-cases. More importantly it eliminates the need for new keywords, actually 
trims one (we only need two for visibility not four) and also eliminates the 
need to find good single-word keywords that make sense on their own, since all 
limited types are explicitly grouped as private which should make it absolutely 
clear.

> On 26 Mar 2016, at 07:14, Cheyo Ximenez via swift-evolution 
>  wrote:
> 
> I agree with Ross. Swift already redefined the common access modifiers 
> meanings. 
> Why not use the word 'protected' to mean 'local'?
> 
> public
> internal
> private
> protected // Java got it wrong. :) This is "protected" against extensions.  
> 
> On Mar 25, 2016, at 6:57 PM, Ross O'Brien via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> The specific meaning of 'public' and 'private' in programming languages 
>> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and 
>> Objective C; their 'public' is Swift's 'internal'. They have no equivalent 
>> to Swift's 'public'. Swift has no equivalent to their 'private'.
>> 
>> Possibly my familiarity with other languages isn't broad enough, but this is 
>> why I haven't understood the idea that Swift's use of 'private' is "right" 
>> or "obvious". You learn Swift's meanings of these terms by coding in Swift, 
>> you don't learn these meanings anywhere else first.
>> 
>> To use a hopefully recognised example: an American who wants 'chips' wants 
>> what a Brit calls crisps; a Brit who wants chips wants what an American 
>> calls french fries. Which meaning of 'chips' is more intuitive? Answer: the 
>> one you grew up with.
>> 
>> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> > all of these names (public, internal, private, local) have specific 
>> > meaning in the context of computer languages.
>> 
>> Yes, `local` has a meaning, but that meaning is generally *not* that it's an 
>> access level. It usually has something to do with declaring variables inside 
>> a function.
>> 
>> For instance, Perl uses it to back up and restore a global variable. ML uses 
>> it to create a scope (roughly). Lua and Julia use it to declare lexical 
>> variables which are visible in enclosed scopes, which SE-0025's new access 
>> level is specifically *not* supposed to allow.
>> 
>> I don't know of any language where `local` is used as an access level. If 
>> you're aware of an analogous use in another language, I'd be interested to 
>> see it. But the examples I've found if anything *undermine* the suggestion 
>> that `local` would be a good keyword choice.
>> 
>> --
>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Cheyo Ximenez via swift-evolution]

I agree with Ross. Swift already redefined the common access modifiers 
meanings. 
Why not use the word 'protected' to mean 'local'?

public
internal
private
protected // Java got it wrong. :) This is "protected" against extensions.  

> On Mar 25, 2016, at 6:57 PM, Ross O'Brien via swift-evolution 
>  wrote:
> 
> The specific meaning of 'public' and 'private' in programming languages 
> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and 
> Objective C; their 'public' is Swift's 'internal'. They have no equivalent to 
> Swift's 'public'. Swift has no equivalent to their 'private'.
> 
> Possibly my familiarity with other languages isn't broad enough, but this is 
> why I haven't understood the idea that Swift's use of 'private' is "right" or 
> "obvious". You learn Swift's meanings of these terms by coding in Swift, you 
> don't learn these meanings anywhere else first.
> 
> To use a hopefully recognised example: an American who wants 'chips' wants 
> what a Brit calls crisps; a Brit who wants chips wants what an American calls 
> french fries. Which meaning of 'chips' is more intuitive? Answer: the one you 
> grew up with.
> 
>> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> > all of these names (public, internal, private, local) have specific 
>> > meaning in the context of computer languages.
>> 
>> Yes, `local` has a meaning, but that meaning is generally *not* that it's an 
>> access level. It usually has something to do with declaring variables inside 
>> a function.
>> 
>> For instance, Perl uses it to back up and restore a global variable. ML uses 
>> it to create a scope (roughly). Lua and Julia use it to declare lexical 
>> variables which are visible in enclosed scopes, which SE-0025's new access 
>> level is specifically *not* supposed to allow.
>> 
>> I don't know of any language where `local` is used as an access level. If 
>> you're aware of an analogous use in another language, I'd be interested to 
>> see it. But the examples I've found if anything *undermine* the suggestion 
>> that `local` would be a good keyword choice.
>> 
>> --
>> 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