Re: [swift-users] How to resolve "type(of: instance)" being shadowed by "instance.type"?

[Glen Huang via swift-users]

Ah, how come I never thought about trying that!?

Thanks!

Regards,
Glen

> On 23 Sep 2017, at 1:10 PM, Slava Pestov  wrote:
> 
> 
>> On Sep 22, 2017, at 10:10 PM, Glen Huang via swift-users 
>>  wrote:
>> 
>> I have a class like this:
>> 
>> class File {
>>  type: FileType
>>  url: URL
>>  func fetch(from server: Server) {
>>  type(of: server).get(from: url)
>>  }
>> }
>> 
>> However, it fails to compile with "Cannot call value of non-function type 
>> ‘File’” inside the body of fetch(from:). I believe the reason is that 
>> self.type shadows  type(of: server).
>> 
>> Other than renaming the “type” property, is there any other way to work 
>> around it? I tried "Foundation.type(of: server)” and found out that it’s 
>> from the standard library and not Foundation. Is there a prefix that denotes 
>> the standard library?
> 
> The standard library module is named ‘Swift’, so ‘Swift.type(of:)’ should do 
> the trick.
> 
>> 
>> A more general question, since this is clearly a function call, why would it 
>> be shadowed by self.type, which is clearly a property access?
>> 
>> I’m using Swift 4 in Xcode 9.
>> 
>> Regards,
>> Glen
>> ___
>> 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] How to resolve "type(of: instance)" being shadowed by "instance.type"?

[Slava Pestov via swift-users]

> On Sep 22, 2017, at 10:10 PM, Glen Huang via swift-users 
>  wrote:
> 
> I have a class like this:
> 
> class File {
>   type: FileType
>   url: URL
>   func fetch(from server: Server) {
>   type(of: server).get(from: url)
>   }
> }
> 
> However, it fails to compile with "Cannot call value of non-function type 
> ‘File’” inside the body of fetch(from:). I believe the reason is that 
> self.type shadows  type(of: server).
> 
> Other than renaming the “type” property, is there any other way to work 
> around it? I tried "Foundation.type(of: server)” and found out that it’s from 
> the standard library and not Foundation. Is there a prefix that denotes the 
> standard library?

The standard library module is named ‘Swift’, so ‘Swift.type(of:)’ should do 
the trick.

> 
> A more general question, since this is clearly a function call, why would it 
> be shadowed by self.type, which is clearly a property access?
> 
> I’m using Swift 4 in Xcode 9.
> 
> Regards,
> Glen
> ___
> 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

[swift-users] How to resolve "type(of: instance)" being shadowed by "instance.type"?

[Glen Huang via swift-users]

I have a class like this:

class File {
   type: FileType
   url: URL
   func fetch(from server: Server) {
   type(of: server).get(from: url)
   }
}

However, it fails to compile with "Cannot call value of non-function type 
‘File’” inside the body of fetch(from:). I believe the reason is that self.type 
shadows  type(of: server).

Other than renaming the “type” property, is there any other way to work around 
it? I tried "Foundation.type(of: server)” and found out that it’s from the 
standard library and not Foundation. Is there a prefix that denotes the 
standard library?

A more general question, since this is clearly a function call, why would it be 
shadowed by self.type, which is clearly a property access?

I’m using Swift 4 in Xcode 9.

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

Re: [swift-users] range(of:options:range:locale:) with partial ranges

[Ben Cohen via swift-users]

In order to be able to use pos… this function would need to be converted from 
it’s current signature (that takes a concrete Range) to be generic over any 
RangeExpression.In this case of this method, the range is optional – and in 
case of nil (which is the default) there would be insufficient context to 
determine the actual type of the RangeExpression. So we’d need to have an 
overload instead.

But none of this ought to be necessary, because constant time slicing and index 
sharing means we don’t need to have functions take optional range arguments any 
more. Instead you can just write str[pos...].range(of: “f”). 

Except... this technique has a bug in it for this particular method when used 
on substrings, that we need to fix before that can be used instead. Hoping for 
that to be fixed on master soon...

> On Sep 21, 2017, at 2:44 AM, Martin R via swift-users  
> wrote:
> 
> The range(of:options:range:locale:) method of StringProtocol does not accept 
> a partial range as search range. Example (Xcode 9, Swift 4):
> 
> let str = "foo"
> let pos = str.startIndex
> let r = str.range(of: "f", range: pos...)
> // error: cannot convert value of type 'PartialRangeFrom'
> // to expected argument type 'Range?'
> 
> Is that because it is an NSString method imported to Swift? Would it make 
> sense to file an enhancement request?
> 
> Regards, Martin
> 
> ___
> 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] Where to report this bug?

[Shawn Erickson via swift-users]

The bug is about the compiler reporting a compile error for a function that
purposely is designed to allow for overflow and handling of said overflow.
It should be allowed to be used in all scopes in code. It seems like the
compiler is able to reason and prove overflow will happen in certain code
scopes (but not all) resulting in a compile time error (which is nice)
however it is doing this with a stdlib function that is meant to deal with
overflow so it should in theory be allowed.

On Fri, Sep 22, 2017 at 8:41 AM Claude Pommerell via swift-users <
swift-users@swift.org> wrote:

> This is not a bug. The error reports correctly that -Int.min cannot be
> represented in the Int type. This holds true for all implementations of
> fixed-size signed integers in Swift and most languages. In fact, Int.min is
> defined as Int.min = -Int.max-1.
>
> The reason is that almost all fixed-sized implementations of signed
> integers can represent an even number of integers. Since zero is both
> positive and negative, they cannot represent an equal number of positive
> and negative numbers. By convention, there is one more negative number,
> because arithmetics is easier to implement electronically this way.
>
> Zero is represented in binary by 000…000, -1 by 111…111, Int.max by
> 011…111, and Int.min by 100…000. The first bit can be interpreted as a sign
> bit, it is 0 for all positive numbers, and 1 for all non-positive (that is,
> smaller than zero) numbers. You can negate all numbers by inverting all of
> their bits and than adding 1, ignoring the overflow to the unrepresentable
> 1000…000 when passing from -1 to 0, and signalling an overflow when
> inverting Int.min. All additions can be implemented as if the binary
> representations were unsigned, checking for overflow only if both terms
> have the same sign.
>
> On 22 Sep 2017, at 03:42, Peter W A Wood via swift-users <
> swift-users@swift.org> wrote:
>
> Entering the following statement in a playground gives an overflow error.
> Where should I report this?
>
> Statement:
>
> Int.min.dividedReportingOverflow(by:-1)
>
> Playground log:
>
> *Playground execution failed:*
>
> *error: MyPlayground.playground:3:9: error: division '-9223372036854775808
> / -1' results in an overflow*
> *Int.min.dividedReportingOverflow(by:-1)*
>
> Peter
> ___
> 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
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Swift Version Conditionals in Objective-C?

[Jon Shier via swift-users]

In moving a hybrid project from Swift 3 to 4, I’ve run into some issues 
from my Objective-C code. I’ve been able to conditionalize my Swift code for 
both versions pretty easily, but there are APIs imported from Objective-C that 
need to change definition for Swift 4. Is there anyway, in preprocessor or at 
runtime, to detect what version of Swift the Objective-C is being imported 
into? It’s as simple as a typedef for NSAttributedString attributes 
dictionaries that needs a different generic type in Swift 3 vs. Swift 4. 
Browsing the documentation I don’t see anything, but I’m guess some such method 
exists, given Apple’s APIs can do so. This would only be a temporary situation 
until the move the Swift 4 can be completed.



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

Re: [swift-users] Where to report this bug?

[Claude Pommerell via swift-users]

This is not a bug. The error reports correctly that -Int.min cannot be 
represented in the Int type. This holds true for all implementations of 
fixed-size signed integers in Swift and most languages. In fact, Int.min is 
defined as Int.min = -Int.max-1.

The reason is that almost all fixed-sized implementations of signed integers 
can represent an even number of integers. Since zero is both positive and 
negative, they cannot represent an equal number of positive and negative 
numbers. By convention, there is one more negative number, because arithmetics 
is easier to implement electronically this way.

Zero is represented in binary by 000…000, -1 by 111…111, Int.max by 011…111, 
and Int.min by 100…000. The first bit can be interpreted as a sign bit, it is 0 
for all positive numbers, and 1 for all non-positive (that is, smaller than 
zero) numbers. You can negate all numbers by inverting all of their bits and 
than adding 1, ignoring the overflow to the unrepresentable 1000…000 when 
passing from -1 to 0, and signalling an overflow when inverting Int.min. All 
additions can be implemented as if the binary representations were unsigned, 
checking for overflow only if both terms have the same sign.

> On 22 Sep 2017, at 03:42, Peter W A Wood via swift-users 
>  wrote:
> 
> Entering the following statement in a playground gives an overflow error. 
> Where should I report this?
> 
> Statement:
> 
> Int.min.dividedReportingOverflow(by:-1)
> 
> Playground log:
> 
> Playground execution failed:
> 
> error: MyPlayground.playground:3:9: error: division '-9223372036854775808 / 
> -1' results in an overflow
> Int.min.dividedReportingOverflow(by:-1)
> 
> Peter
> ___
> 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] Where to report this bug?

[Martin R via swift-users]

Filed as https://bugs.swift.org/browse/SR-5964 


Martin

> On 22. Sep 2017, at 12:11, Alex Blewitt  wrote:
> 
> Hmm... probably worth filing a bug at https://bugs.swift.org 
>  then with the below test case.
> 
> Alex
> 
>> On 22 Sep 2017, at 10:14, Martin R > > wrote:
>> 
>> But the purpose of 
>> 
>> func dividedReportingOverflow(by other: Int 
>> ) -> (partialValue: Int 
>> , overflow: Bool 
>> )
>> 
>> is to report an overflow in the return value. And actually this compiles and 
>> runs in Xcode 9 if the code is on top-level in main.m:
>> 
>> let minusOne = -1
>> let r1 = Int.min.dividedReportingOverflow(by: minusOne)
>> print(r1) // (partialValue: -9223372036854775808, overflow: true)
>> 
>> let zero = 0
>> let r2 = Int.min.dividedReportingOverflow(by: zero)
>> print(r2) // (partialValue: -9223372036854775808, overflow: true)
>> 
>> But the same code inside a function (or do-block) fails to compile:
>> 
>> func foo() {
>> let minusOne = -1
>> let r1 = Int.min.dividedReportingOverflow(by: minusOne)
>> // error: division '-9223372036854775808 / -1' results in an overflow
>> print(r1)
>> 
>> let zero = 0
>> let r2 = Int.min.dividedReportingOverflow(by: zero)
>> // error: division by zero
>> print(r2)
>>}
>> 
>> Martin
>> 
>> 
>>> On 22. Sep 2017, at 10:19, Alex Blewitt via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
>>> Int.min is the smallest negative value, and Int.max is the largest positive 
>>> value (that fits in an Int). However, the absolute value of Int.min is 
>>> larger than the absolute value of Int.max. So you can't convert Int.min 
>>> into -Int.min because it's larger than Int.max.
>>> 
>>> In other words, this is expected behaviour :)
>>> 
>>> For example:
>>> 
>>> Int.min + Int.max = 1
>>> 
>>> If they were the same value, it would be zero.
>>> 
>>> Alex
>>> 
 On 22 Sep 2017, at 02:42, Peter W A Wood via swift-users 
 mailto:swift-users@swift.org>> wrote:
 
 Entering the following statement in a playground gives an overflow error. 
 Where should I report this?
 
 Statement:
 
 Int.min.dividedReportingOverflow(by:-1)
 
 Playground log:
 
 Playground execution failed:
 
 error: MyPlayground.playground:3:9: error: division '-9223372036854775808 
 / -1' results in an overflow
 Int.min.dividedReportingOverflow(by:-1)
 
 Peter
 ___
 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 
>>> 
>> 
> 

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

Re: [swift-users] Where to report this bug?

[Alex Blewitt via swift-users]

Hmm... probably worth filing a bug at https://bugs.swift.org 
 then with the below test case.

Alex

> On 22 Sep 2017, at 10:14, Martin R  wrote:
> 
> But the purpose of 
> 
> func dividedReportingOverflow(by other: Int 
> ) -> (partialValue: Int 
> , overflow: Bool 
> )
> 
> is to report an overflow in the return value. And actually this compiles and 
> runs in Xcode 9 if the code is on top-level in main.m:
> 
> let minusOne = -1
> let r1 = Int.min.dividedReportingOverflow(by: minusOne)
> print(r1) // (partialValue: -9223372036854775808, overflow: true)
> 
> let zero = 0
> let r2 = Int.min.dividedReportingOverflow(by: zero)
> print(r2) // (partialValue: -9223372036854775808, overflow: true)
> 
> But the same code inside a function (or do-block) fails to compile:
> 
> func foo() {
> let minusOne = -1
> let r1 = Int.min.dividedReportingOverflow(by: minusOne)
> // error: division '-9223372036854775808 / -1' results in an overflow
> print(r1)
> 
> let zero = 0
> let r2 = Int.min.dividedReportingOverflow(by: zero)
> // error: division by zero
> print(r2)
>}
> 
> Martin
> 
> 
>> On 22. Sep 2017, at 10:19, Alex Blewitt via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> Int.min is the smallest negative value, and Int.max is the largest positive 
>> value (that fits in an Int). However, the absolute value of Int.min is 
>> larger than the absolute value of Int.max. So you can't convert Int.min into 
>> -Int.min because it's larger than Int.max.
>> 
>> In other words, this is expected behaviour :)
>> 
>> For example:
>> 
>> Int.min + Int.max = 1
>> 
>> If they were the same value, it would be zero.
>> 
>> Alex
>> 
>>> On 22 Sep 2017, at 02:42, Peter W A Wood via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
>>> Entering the following statement in a playground gives an overflow error. 
>>> Where should I report this?
>>> 
>>> Statement:
>>> 
>>> Int.min.dividedReportingOverflow(by:-1)
>>> 
>>> Playground log:
>>> 
>>> Playground execution failed:
>>> 
>>> error: MyPlayground.playground:3:9: error: division '-9223372036854775808 / 
>>> -1' results in an overflow
>>> Int.min.dividedReportingOverflow(by:-1)
>>> 
>>> Peter
>>> ___
>>> 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
> 

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

[swift-users] Threads and weak references

[Howard Lovatt via swift-users]

Hi,

I was using a weak reference in a concurrent application and and the main
thread wasn't seeing an update to a class's property made by another
thread. If I replaced the weak reference with a closure, the problem went
away.

Is there any documentation that describes this behaviour?

Thanks in advance for any help,

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

Re: [swift-users] Where to report this bug?

[Martin R via swift-users]

But the purpose of 

func dividedReportingOverflow(by other: Int 
) -> (partialValue: Int 
, overflow: Bool 
)

is to report an overflow in the return value. And actually this compiles and 
runs in Xcode 9 if the code is on top-level in main.m:

let minusOne = -1
let r1 = Int.min.dividedReportingOverflow(by: minusOne)
print(r1) // (partialValue: -9223372036854775808, overflow: true)

let zero = 0
let r2 = Int.min.dividedReportingOverflow(by: zero)
print(r2) // (partialValue: -9223372036854775808, overflow: true)

But the same code inside a function (or do-block) fails to compile:

func foo() {
let minusOne = -1
let r1 = Int.min.dividedReportingOverflow(by: minusOne)
// error: division '-9223372036854775808 / -1' results in an overflow
print(r1)

let zero = 0
let r2 = Int.min.dividedReportingOverflow(by: zero)
// error: division by zero
print(r2)
   }

Martin


> On 22. Sep 2017, at 10:19, Alex Blewitt via swift-users 
>  wrote:
> 
> Int.min is the smallest negative value, and Int.max is the largest positive 
> value (that fits in an Int). However, the absolute value of Int.min is larger 
> than the absolute value of Int.max. So you can't convert Int.min into 
> -Int.min because it's larger than Int.max.
> 
> In other words, this is expected behaviour :)
> 
> For example:
> 
> Int.min + Int.max = 1
> 
> If they were the same value, it would be zero.
> 
> Alex
> 
>> On 22 Sep 2017, at 02:42, Peter W A Wood via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> Entering the following statement in a playground gives an overflow error. 
>> Where should I report this?
>> 
>> Statement:
>> 
>> Int.min.dividedReportingOverflow(by:-1)
>> 
>> Playground log:
>> 
>> Playground execution failed:
>> 
>> error: MyPlayground.playground:3:9: error: division '-9223372036854775808 / 
>> -1' results in an overflow
>> Int.min.dividedReportingOverflow(by:-1)
>> 
>> Peter
>> ___
>> 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

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

Re: [swift-users] Where to report this bug?

[Alex Blewitt via swift-users]

Int.min is the smallest negative value, and Int.max is the largest positive 
value (that fits in an Int). However, the absolute value of Int.min is larger 
than the absolute value of Int.max. So you can't convert Int.min into -Int.min 
because it's larger than Int.max.

In other words, this is expected behaviour :)

For example:

Int.min + Int.max = 1

If they were the same value, it would be zero.

Alex

> On 22 Sep 2017, at 02:42, Peter W A Wood via swift-users 
>  wrote:
> 
> Entering the following statement in a playground gives an overflow error. 
> Where should I report this?
> 
> Statement:
> 
> Int.min.dividedReportingOverflow(by:-1)
> 
> Playground log:
> 
> Playground execution failed:
> 
> error: MyPlayground.playground:3:9: error: division '-9223372036854775808 / 
> -1' results in an overflow
> Int.min.dividedReportingOverflow(by:-1)
> 
> Peter
> ___
> 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