Re: [swift-evolution] Strings in Swift 4

[Bernd Ohr (jazzbox) via swift-evolution]

> Am 21.01.2017 um 21:31 schrieb Dave Abrahams via swift-evolution 
> :
> 
>> I'm struggling a little with the naming and syntax, but as a general 
>> approach, I think we want people to use something more like this:
>> 
>>if StringOptions(case: .insensitive, locale: .current).compare(foo < bar) 
>> { … }
> 
> Yeah, we can't do that without making 
> 
>   let a = foo < bar
> 
> ambiguous
> 

Hi,

the most swifty way to write this I can imagine is something like:

func <(_ a: Int, _ b: Int, case: Case = .insensitive, locale: Locale = 
.current)

let a = foo < bar where <(case: .insensitive, locale: .current) 

In other words, function or operator calls can be splitted:

func foo(_ a: Int, _ b: Int, option: Option)

let res = foo(10, 20) where foo(option: .fast)

And where it is unambiguous the second function or operator name can be omitted:

let a = foo < bar where (case: .insensitive, locale: .current)

...or shared:

let a = foo1 < bar1 && foo2 < bar2 where (case: .insensitive, locale: 
.current)

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Bernd Ohr (jazzbox) via swift-evolution]

I am using a typealias for this:

struct MyStruct {
private typealias _Self = MyStruct

static func staticMethod() { print("staticMethod") }

func instanceMethod() {
_Self.staticMethod()
}
}



> > On Apr 5, 2016, at 4:17 PM, Timothy 
> > Woodwrote:
> > 
> > > On Apr 5, 2016, at 3:04 PM, Joe Groff via 
> > > swift-evolutionwrote:
> > > What you're describing should be spelled `Self`, IMO. I think Tim 
> > > intended `#Self` to mean the *static* type the code is declared inside 
> > > (which is the same as Self unless you're in a class).
> > 
> > Yes, that is what I was aiming for. `#Self` would be a pretty much textual 
> > replacement just like #file, etc. That is, I could imaging it being used in 
> > a bunch of cases (not useful here, but just intending to enumerate the 
> > possible uses I see):
> Please check to ensure that the changes I just made match your expectations:
> 
> https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227
> 
> -- E
> 

___
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

[swift-evolution] [Review] SE-0042 Flattening the function type of unapplied method references

[Bernd Ohr (jazzbox) via swift-evolution]

Sorry for being late!

I am not quite sure!

Although I believe that this is a step in the right direction (inout 
parameters), I would like to see a more general approach where the unapplied 
method reference produces not one but ALL possible references!

That means that taking the unspecified reference gives an error when there are 
two ore more possible solutions (definitions are taken from Joe Groff's 
proposal):

let f0 = Type.instanceMethod // Error: Type.instanceMethod is ambiguous

Further type specification makes the assignment unambigous:

let f1: (Type, y: Int) -> Int = Type.instanceMethod // OK

let f2: (Type) -> (y: Int) -> Int = Type.instanceMethod // OK

let f3: (y: Int) -> (Type) -> Int = Type.instanceMethod // OK??

Functions like map and reduce then will select the appropriate reference 
automatically.


However, I must admit that this idea arose rather from a theoretical 
consideration...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution