Re: [swift-users] Type inference issue with map and filter chained

[Vladimir.S via swift-users]

On 03.10.2017 21:32, Will Stanton via swift-users wrote:

Is this a REPL-only issue perhaps? The code below compiles `swift build` 
without error for me (pasted into Sources/main.swift, Ubuntu 17.04, Swift 4 
release; haven’t tried in Xcode).


A similar issue, but apparently not REPL-only:
https://bugs.swift.org/browse/SR-1856

Regards,
Will Stanton


Code compiles fine:
class test {
 let id = 11
}

var dict: [Int: test] = [10: test()]

let filtered = dict.filter({ $0.value.id > 10 })
let sorted = filtered.sorted(by: {$0.value.id > $1.value.id })

print(sorted)

let filteredAndSorted = dict.filter({ $0.value.id > 10 }).sorted(by: {$0.value.id 
> $1.value.id })


Just checked:

XCode 9: "Ambiguous use of 'filter'" error for this line

Vladimir.


print(filteredAndSorted)



On Sep 24, 2017, at 4:52 AM, Trevör ANNE DENISE via swift-users 
 wrote:

Hello everyone, I found this on StackOverflow : 
https://stackoverflow.com/questions/46381752/swift-4-methods-chaining/

Is this a bug of Swift 4 or is this normal ? I don't understand why the problem 
only happens when methods are chained !



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


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

Re: [swift-users] Netlib

[Vladimir.S via swift-users]

On 03.10.2017 19:02, Edward Connell via swift-users wrote:

Hi All,
Sorry something strange happened with the first post, so I am reposting this.

I've recently wrapped up an ML framework research project that I've been working on 
for some time.
It addresses a lot of difficult design problems, and works around a lot of compiler 
bugs and Linux library deficiencies.


It's written almost entirely in Swift 4.0 with some C and Cuda kernels.
Development and testing were done primarily on Ubuntu 16.04, but it will also build 
on MacOS.
Linux was the primary environment, because there aren't any modern Macs that can host 
big NVIDIA hardware


The framework interfaces with many common C libraries such as: *Cuda, cuDNN, lmdb, 
png, jpeg, zlib*


Anyone in the community that is trying to work with these libraries might benefit 
from the Swift wrapper classes and examples of successful use. There are other 
isolated technology pieces that might be of use also.


Other people's projects and examples helped me along the way, so I am hoping that my 
work will help some of you as well.


The code and overview docs are published on GitHub

docs: https://github.com/ewconnell/Netlib/wiki 

code: https://github.com/ewconnell/Netlib 



Ed, it looks awesome! :-) Thank you for doing this and for sharing this!

I'm a beginner in ML world, so could you clarify some points please:

1. Do I understand correctly, that main purpose of your library is to train the 
model? So, then we can export structure(connections) and use them where we 
need? Or also the purpose is efficient 'calculation' of trained model on Mac/Linux, 
so this could be used in production apps?


2. Currently this library has only Cuda compute service implemented, right? Do you 
plan to implement the same for Metal soon?


3. What are your plans to support iOs and its Metal? So, the same library/code/way 
could be used to train/experiment and to 'use' in apps on all(macOS/Linux/iOS) platforms.


Thank you.
Vladimir.


Happy coding, Ed :)


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


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

Re: [swift-users] Swift 4 "Cannot use mutating member on immutable value: 'self' is immutable"

[Vladimir.S via swift-users]

On 17.09.2017 13:25, Quinn "The Eskimo!" via swift-users wrote:


On 15 Sep 2017, at 21:35, Vladimir.S via swift-users <swift-users@swift.org> 
wrote:


… for me it is very strange decision to disallow a method because it is 
'expensive'.


That’s pretty normal for Swift standard library protocols, which define not 
just the behaviour of the routine but expected performance.  `popFirst()` is 
expected to be O(1) and that’s not possible with `Array`.

The rationale behind this decision is, I believe, related to generic 
algorithms.  If I write generic code that uses `popFirst()`, I can only 
guarantee the complexity of my code if I can rely on `popFirst()` being O(1).  
If someone implements `popFirst()` as O(n), my generic algorithm might go from 
O(n^2) to O(n^3), which is quite a change.


Do I understand this correctly?: To protect *me* from using popFirst() with possible 
O(n) complexity in my *generic code*, there is no better solution in Swift than just 
*hide* the method from me even in non-generic code. Even if I probably don't care 
about the complexity for my 5 elements array.
And so, I should use hacky code like this(which doesn't produce warnings/errors) to 
fight with compiler:

let x = array[0...].popFirst()

Can't understand/accept this, sorry. If you are saying "this is a current limitation 
we have" - ok, but when you are saying "That’s pretty normal" - I don't understand 
what "normal" means here. I even can understand if compiler can provide us with some 
'popFirstNComplexity()'(or warning with a way to silence it) when 'popFirst' 
shouldn't be accessible because of reasons mentioned by you. But just hide the method.



Also, could you clarify, why .removeFirst() is different? We can use it without 
problems:

var array = [1, 2, 3, 4, 5]
array.removeFirst() // no warnings
print(array) // [2,3,4,5]

Vladimir.



On 16 Sep 2017, at 01:44, Rick Mann via swift-users <swift-users@swift.org> 
wrote:


Is the compiler looking at the name "pop" and adding additional constraints 
(and then spewing a bogus error message)?


I’m not sure what’s going on here mechanically but, yes, the error message is 
bogus.  This is exactly what SR-5515 is talking about.

If I were in your shoes I’d call this method something other than `popFirst()`. 
 This falls under my standard “if you change the semantics, change the name” 
rule.  Your implementation of `popFirst()` doesn’t conform to the semantics of 
`popFirst()` — it’s O(n) because `removeFirst()` is O(n) — and thus you want to 
avoid calling it `popFirst()`.

Share and Enjoy
--
Quinn "The Eskimo!"<http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


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


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

Re: [swift-users] Swift 4 "Cannot use mutating member on immutable value: 'self' is immutable"

[Vladimir.S via swift-users]

On 14.09.2017 22:02, Jon Shier via swift-users wrote:
Looks like this is sort of tracked in  SR-5515popFirst error message is silly 
<https://bugs.swift.org/browse/SR-5515>. I’m not sure what a good answer is here, 
since it seems like it isn’t supposed to be available if it can’t guarantee O(1) 
behavior. Still seems like Array should have it, but in any case, this looks like a 
bad error message at least.


But can .removeFirst() guarantee this? I don't believe these two methods a very 
different in implementation. And, as I said, for me it is very strange decision to 
disallow a method because it is 'expensive'. I hope this is just a bug, that will be 
fixed.


Vladimir.





Jon


On Sep 14, 2017, at 11:05 AM, Jon Shier via swift-users <swift-users@swift.org 
<mailto:swift-users@swift.org>> wrote:


This seems oddly similar to https://bugs.swift.org/browse/SR-5659, but [Thing] 
should meet the appropriate criteria for popFirst to work properly. Yet the error 
we’re seeing here is the same that was originally seen when trying to use popFirst 
on a String. Definitely feels like some sort of Swift bug here.




Jon


On Sep 14, 2017, at 10:48 AM, Jon Shier via swift-users <swift-users@swift.org 
<mailto:swift-users@swift.org>> wrote:


It also doesn’t explain why removeFirst would work but popFirst doesn’t. The 
mutation to the underlying array should be the same, the only different is that 
one returns the element optionally. It also doesn’t explain why popFirst doesn’t 
show up I the autocomplete but compiles anyway.




Jon

On Sep 14, 2017, at 8:16 AM, Vladimir.S via swift-users <swift-users@swift.org 
<mailto:swift-users@swift.org>> wrote:


On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:
On 14 Sep 2017, at 03:56, somu subscribe via swift-users <swift-users@swift.org 
<mailto:swift-users@swift.org>> wrote:

popFirst is not available in the Array …
Right.  This makes sense when you consider the standard setup for an array, 
namely, a variable length buffer of items.  Removing the first element is 
expensive, whereas removing the last element (`popLast()`) is cheap.
If you run your simplified example in Xcode 8 you get an error that hints at 
what’s going on.

var array = [1, 2, 3, 4, 5]
_ = array.popFirst()
~~^~~~
error: 'ArraySlice' is not convertible to '[Int]'


Sorry, could you clarify, I can't understand.
What should be the error message here and why at all we should have an error 
here?

Are we forced to use this code to pop first element in array? :
var array = [1, 2, 3, 4, 5]
let x = array[0...].popFirst()
print(x!) // 1
print(array) // [2,3,4,5]

And why we shouldn't be allowed to have popFirst() for array? Yes, it is 
expensive, but is it a right reason to disallow it totally? In many situations we 
have a small arrays and don't care so much how fast the first element will be pop'ed.

I hope I'm just missing something.

Vladimir.

Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with a new 
command line tool project) and I get the same error there.

let mf = self.pendingFetchers.popFirst()
 ~^~~~
error: 'ArraySlice' is not convertible to '[ModelFetcher]’
   *   *   *
@Rick, there’s two things in play here:
* The diagnostic is clearly bogus and you should definitely file a bug about 
that.
<https://bugs.swift.org/>
Please post your bug number, just for the record.
* You wrote:

This code compiled fine in Xcode 8 …
My tests indicate that it doesn’t.  I suspect that you changed something else 
during the Swift 4 migration and that’s why you’re seeing it fail.  Can you take 
another look at the original Xcode 8 code to see what’s else got changed?

Share and Enjoy
--
Quinn "The Eskimo!"<http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
___
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users


___
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users


___
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users




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


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

Re: [swift-users] Swift 4 "Cannot use mutating member on immutable value: 'self' is immutable"

[Vladimir.S via swift-users]

On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:


On 14 Sep 2017, at 03:56, somu subscribe via swift-users 
 wrote:


popFirst is not available in the Array …


Right.  This makes sense when you consider the standard setup for an array, 
namely, a variable length buffer of items.  Removing the first element is 
expensive, whereas removing the last element (`popLast()`) is cheap.

If you run your simplified example in Xcode 8 you get an error that hints at 
what’s going on.

var array = [1, 2, 3, 4, 5]
_ = array.popFirst()
 ~~^~~~
error: 'ArraySlice' is not convertible to '[Int]'



Sorry, could you clarify, I can't understand.
What should be the error message here and why at all we should have an error 
here?

Are we forced to use this code to pop first element in array? :
var array = [1, 2, 3, 4, 5]
let x = array[0...].popFirst()
print(x!) // 1
print(array) // [2,3,4,5]

And why we shouldn't be allowed to have popFirst() for array? Yes, it is expensive, 
but is it a right reason to disallow it totally? In many situations we have a small 
arrays and don't care so much how fast the first element will be pop'ed.

I hope I'm just missing something.

Vladimir.


Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with a 
new command line tool project) and I get the same error there.

let mf = self.pendingFetchers.popFirst()
  ~^~~~
error: 'ArraySlice' is not convertible to '[ModelFetcher]’

*   *   *

@Rick, there’s two things in play here:

* The diagnostic is clearly bogus and you should definitely file a bug about 
that.



Please post your bug number, just for the record.

* You wrote:


This code compiled fine in Xcode 8 …


My tests indicate that it doesn’t.  I suspect that you changed something else 
during the Swift 4 migration and that’s why you’re seeing it fail.  Can you 
take another look at the original Xcode 8 code to see what’s else got changed?

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


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


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

Re: [swift-users] ⁨Is it possible to store a set of heterogeneous items with protocol?

[Vladimir.S via swift-users]

On 17.07.2017 4:51, Glen Huang via swift-users wrote:
Thanks for the code sample and link, but if I’m not wrong, this pattern doesn’t allow 
heterogeneous items.


Support the question. Trying to understand if we can have something like 
[AnyHashable] for our custom protocol(with associated type) or AnyHashable has a very 
special support from compiler and we can use only [Any] or such kind of wrapper:


struct AnyMyProtocol {
  let actualInstance: Any
  init(_ instance: T) { actualInstance = instance}
}

let instances: [AnyMyProtocol] = [AnyMyProtocol(...), AnyMyProtocol(...)]

if let some = instances[0].actualInstance as? 
SpecificImplementationOfMyProtocol {
// use 'some' as SpecificImplementationMyProtocol instance
// seems like no way to refer to just MyProtocol
}




If I have these definitions:

struct Chicken {}
struct Pig {}

class ChickenFarm: Farm {
 func grow() -> Chicken {
 return Chicken()
 }
}

class PigFarm: Farm {
 func grow() -> Pig {
 return Pig()
 }
}

Then:

var farms = // How do I define a set that can contain both ChickenFarm and 
PigFarm?
farms.insert(AnyFarm(ChickenFarm()))
farms.insert(AnyFarm(PigFarm()))


On 17 Jul 2017, at 4:02 AM, Nevin Brackett-Rozinsky 
> wrote:


The standard pattern for type-erasure in Swift looks like this:

protocol Farm {
associatedtype Produce
func grow() -> Produce
}

private class _AnyFarmBase : Farm {
func grow() -> T { fatalError() }
}

private final class _AnyFarmBox: _AnyFarmBase {
var farm: U
init(_ x: U) { farm = x }
override func grow() -> U.Produce {
return farm.grow()
}
}

public final class AnyFarm : Farm {
private let wrapped: _AnyFarmBase
func grow() -> V { return wrapped.grow() }
init (_ x: W) where W.Produce == V {
wrapped = _AnyFarmBox(x)
}
}


There is one little hiccough when you need an initializer in the abstract base 
class, which you can read about here 
 among 
other places.


Hope that helps,

Nevin


On Sun, Jul 16, 2017 at 12:32 AM, Glen Huang via swift-users > wrote:


This sounds like the right approach!

However, as I experimented with AnyHashable more, I found out that after
converting a concrete type to it, I could still convert back using “as”:

AnyHashable(Foo()) as! Foo

I guess that’s not the case with AnyNamed? I tried to imitate AnyHashable:

struct AnyNamed: Named {
let base: Any
init(_ value: T) {
base = value
}

var name: String {
// How do I convert `base` to `Named` here?
}
}

But I have no idea what to put in `var name: String`. Also, even if we 
managed
to come up with a solution, would it magically allow direct casting with 
“as”?
Does the complier do something special for AnyHashable?


> On 16 Jul 2017, at 12:58 AM, Ole Begemann > wrote:
>
> One way to do this in Swift is a method called type erasure.
>
> Type erasure means you create a new type that wraps any value whose 
concrete
type you want to erase. This new type also conforms to the protocol. By
convention the type is named Any... (compare AnyIterator and AnySequence in 
the
standard library, which do the same thing).
>
> struct AnyNamed: Named {
>private let _name: () -> String
>
>init(_ value: T) {
>_name = { value.name  }
>}
>
>var name: String {
>return _name()
>}
> }
>
> AnyNamed is initialized with a generic value T: Named. Notice that the
initializer is generic, but the type itself isn't. Because AnyNamed can't 
store
value: T directly (then it would have to be generic over T), we create a
closure over value.name  and store that instead.
>
> Now we can create a Set and, because AnyNamed conforms to Named,
treat the set's elements as values conforming to Named:
>
> var set = Set()
> set.insert(AnyNamed(Foo()))
> set.insert(AnyNamed(Bar()))
>
> for element in set {
>print(element.name )
>print(element.hashValue)
> }
>
>
> On 11.07.2017 12:10, Glen Huang via swift-users wrote:
>> Hi,
>>
>> I want to store some heterogeneous items all conform to a protocol 
inside a
set, is it something possible to do in swift?
>>
>> I tried this example:
>>
>> ```
>> protocol Named: Hashable {
>>var name: String { get }
>> }
>>
>> extension Named {
>>var hashValue: Int {
>>return name.hashValue
>>}
>>
>>static func ==(lhs: Self, rhs: Self) -> Bool {
>>   

Re: [swift-users] UserDefaults with generic keys

[Vladimir.S via swift-users]

On 07.07.2017 14:02, Thierry Passeron via swift-users wrote:

Hi Everyone,

Using Swift 3.1, I was wondering if I could come up with something largely 
inspired by Notification.Name to help me deal with UserDefaults so I started by 
doing something like:


The only kind of solution I was able to implement, is with calculated properties in 
extension. Hope this have any sense and most likely can be improved(code from swift 
sandbox):


struct DefaultsKey {
var rawValue : String

init(_ name: String) {
rawValue = name
}
}

extension DefaultsKey {
static var version : DefaultsKey { return 
DefaultsKey("version") }
static var code : DefaultsKey { return DefaultsKey("code") }
}

func UserDefaults_standard_object(forKey: String) -> Any? {
switch forKey {
case "version" : return "1.0.0"
case "code" : return 12345
default : return nil
}
}

func Defaults(_ key: DefaultsKey) -> T? {
  return UserDefaults_standard_object(forKey: key.rawValue) as? T
}

let version = Defaults(.version)
let code = Defaults(.code)

print(version ?? "-no value-", type(of: version)) // 1.0.0 Optional
print(code ?? "-no value-", type(of: code))   // 12345 Optional





public struct DefaultsKey: RawRepresentable, Equatable, Hashable, Comparable {
   
   public var rawValue: String

   public var hashValue: Int { return rawValue.hash }
   
   public init(_ rawValue: String) { self.rawValue = rawValue }

   public init(rawValue: String) { self.rawValue = rawValue }
   
   /* Protocols implementation .. */

}

Now I can make extensions like:

extension DefaultsKey {
   static let version = DefaultsKey("version »)
}

And use it to query the UserDefaults.

public func Defaults(_ key: DefaultsKey) -> T? {
   return UserDefaults.standard.object(forKey: key.rawValue) as? T
}

let version: String? = Defaults(.version)

Nice, concise, I love it…

But It could be even better to let the compiler check the return type of the 
UserDefault for the DefaultKey that I ask if only I could create the key and 
bind it to a type. So I tried this:

public struct DefaultsKey: RawRepresentable, Equatable, Hashable, Comparable 
{
…
}

extension DefaultsKey {
   static let version = DefaultsKey("version »)
}

But this doesn’t compile:
error: static stored properties not supported in generic types

I guess I could keep all the keys outside an extension scope but then it would 
not be as concise as with Notification.Name

Please let me know if there is indeed a generic way to solve this. Any help 
would be greatly appreciated.
Thanks in advance.

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


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

Re: [swift-users] did i just imagine tuples were going to be hashable in swift 4?

[Vladimir.S via swift-users]

On 07.07.2017 5:50, David Baraff via swift-users wrote:

I thought I read that tuples would finally be hashable in swift 4, allowing for 
them to be used in dictionaries/sets, but now that i google for it, i find no 
mention of it.

are there any plans?  so often i just want to quickly create a dictionary set 
from a tuple of an integer or string or two, and not being able to do so is 
just plain annoying.


Here what I can find regarding your question:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033858.html

--- quote ---
...
> Btw, what is your opinion, can we expect (at some point of time) 
Equatable for tuples?
> It is very handy to have Dictionary, type3> in C# and sad that 
we can't have [(type1,type2):type3] in Swift without declaration of new temporary 
struct type and implement Equatable for it.


It would be reasonable, IMO, even before we support the full generalization of 
extensions on non-nominal types, to make tuples of Equatable/Hashable/Comparable 
elements conform to the same protocols by fiat.


-Joe
--- quote ---

So... it seems like we all (including core team) want this, but this will not be 
implemented in Swift4, as I understand.




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


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

Re: [swift-users] override-like keyword for default implementations

[Vladimir.S via swift-users]

On 16.05.2017 20:44, Charles Srstka via swift-users wrote:
On May 16, 2017, at 12:32 PM, Nevin Brackett-Rozinsky via swift-users 
> wrote:


There is not.

At some point in the future, I believe the plan is to eventually allow default 
implementations to be written in-line within the protocol declaration itself. In 
other words, the fact that default implementations currently must appear in 
extensions, is a temporary limitation that has not yet been a priority to address.


Very interested, why do you have this impression? I didn't see this idea in the list 
previously(probably I just missed it). I strongly believe there can't be such 'plan'.




Once we gain the ability to define default implementations within protocols 
themselves, rather than extensions, then your use-case will “just work” (at least 
as long as you control the protocol anyway). I wouldn’t hold my breath though, as 
that behavior will not appear this year, and the plans for next year have not been 
hashed out yet.


Even that won’t completely solve the problem, though, because:

protocol P {
func foo() {
// default implementation
}
}

struct S: P {
func foo() {
// overriden implementation
}
}

If foo is refactored here, S will start getting the wrong implementation of it, 
silently, with no warning.


People have tried to bring up proposals to add some sort of “override”-like keyword 
for protocols on swift-evolution a bunch of times, but it always gets shouted down by 
certain members of the group, so we’re probably permanently stuck with this situation 
where a supposedly “protocol-oriented” language is not safe to use with protocols.


Exactly!
I can remember these related threads in swift-evolution:
"Requiring proactive overrides for default protocol implementations"
"Requiring special keyword to mark protocol implementation methods"




Charles



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


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

Re: [swift-users] Swift 3.1 String(

[Vladimir.S via swift-users]

On 05.04.2017 20:30, David Sweeris via swift-users wrote:



On Apr 5, 2017, at 07:49, Rien via swift-users  wrote:



On 05 Apr 2017, at 16:26, Maxim Veksler via swift-users  
wrote:

Hi,

Swift 3.1 compiler seems to introduces a new complier warning regarding 
String(describing: )

So this line:
Log.info("Update name for user \(fbUser)”)


Log.info(“Update name for user \(fbUser ?? “Unknown”)”)


I thought we couldn't nest quotes. Has that changed (because that would be 
fantastic)?


Yes, this is working currently.
Btw, also should be mentioned that fbUser.debugDescription can be used 
explicitly to silence the warning, but 'Optional("username")' will be 
printed in log (instead of just 'username').




- Dave Sweeris
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


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

Re: [swift-users] [swift-evolution] [Question] Types of functions

[Vladimir.S via swift-users]

On 12.11.2016 11:38, Adrian Zubarev via swift-users wrote:

(Adrian, are you from the future? ;-)


We should move this thread to swift-users.

Here is something that I just tried:

|func foo(_: Int, _: Int) {} func boo(_: (Int, Int)) {} type(of: foo) ==
type(of: boo) //=> true ; (((Int, Int)) -> ()).Type let tuple = (0, 42)
foo(tuple) // Tuple splat was removed => Error boo(tuple) // Expected => Okay |



IIUC, as soon as 
SE-0110(https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md) 
was not marked as "implemented" yet according to 
https://apple.github.io/swift-evolution/, we still have some rudiments of 
older design.


I expect that implementation of SE-0110 will separate types
(Int, Int) -> ()
and
((Int, Int)) -> ()

Also implementation of SE-0110 should remove implicit Void parameter in 
function defined with no parameters


func f() {}
func g() {}
f(g()) // now works, will be error

func foo(f: () -> ()) { f() }
foo {x in print(x)} // now works, will be error


I'd really like to know when this proposal will be implemented : in Swift 
3.x or in 4.x





--
Adrian Zubarev
Sent with Airmail

Am 5. Oktober 2016 um 17:02:43, Anton Zhilin via swift-evolution
(swift-evolut...@swift.org ) schrieb:


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




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


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

Re: [swift-users] xcode8 segmentation fault help

[Vladimir.S via swift-users]

On 27.09.2016 12:51, Luis Ferro via swift-users wrote:

let string = "a simple test"
if (string.characters.count > 0) {
let words = string.components(separatedBy: " ")
let headline = words.map { (var word) -> String in
let firstCharacter = word.remove(at: word.startIndex)
return "\(String(firstCharacter).uppercased())\(word)"
}.joined(separator: " ")
}


Swift 3.0 does not support `var` in function/closure parameter list. For 
some reason Swift parser didn't catch this as syntax error, I'd suggest you 
to report a bug on bugs.swift.org.


This version works:

let string = "a simple test"
if (string.characters.count > 0) {
let words = string.components(separatedBy: " ")
let headline = words.map { wordParam -> String in //<<< immutable
var word = wordParam //<<< assign to mutable instance
let firstCharacter = word.remove(at: word.startIndex)
return "\(String(firstCharacter).uppercased())\(word)"
}.joined(separator: " ")
}
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users