Re: [swift-users] Synthesized Equatable Bug?

[Dmitri Gribenko via swift-users]

On Mon, Jan 15, 2018 at 2:30 PM, Jon Shier via swift-users
 wrote:
> This is pretty straightforward code, so am I missing something here?

Your '<' function does not define a valid strict total order.

For

let p1 = Point(1, 1)
let p2 = Point(0, 2)

neither of 'p1 < p2', 'p2 < p1', 'p1 == p2' is true.  This is the root cause.

> static func <= (lhs: Point, rhs: Point) -> Bool {
>return lhs < rhs || lhs == rhs
> }

A faster way to compute it (with only one call to a user-defined
comparison operator) is to return '!(rhs < lhs)', which is wat the
standard library does, which is why you see the behavior that you are
seeing.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Subtract a set of a subclass?

[Dmitri Gribenko via swift-users]

On Sat, Sep 3, 2016 at 4:47 AM, Zhao Xin via swift-users
 wrote:
> Hi Jordan,
>
> Both you and I were wrong.
>
> My wrongness: Your so called principle should be applied here.
>
> Your wrongness: If you really want a different hash value, the parent
> equality function has to be conservative and say that the different types
> are different.

That's one way you can satisfy the rules, but not the only one.

Think about class clusters.  NSString has many subclasses that store
strings in different ways (for example, as Latin1 and UTF-16), but any
subclass instance compares equal to any other subclass instance that
carries the same character data, and also produces the same hash
value.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Can we `override var hashValue`?

[Dmitri Gribenko via swift-users]

On Sat, Sep 3, 2016 at 1:31 AM, Zhao Xin via swift-users
 wrote:
> func ==(lhs: Apple, rhs: Apple) -> Bool {
> return lhs.name == rhs.name && lhs.shape == rhs.shape
> }
>
> func ==(lhs: Banana, rhs: Banana) -> Bool {
> return lhs.name == rhs.name && lhs.shape == rhs.shape
> }

There is no reason to compare the shape, it is a constant in each of
these types.  (So I am not sure what your point is.)

> My question is, apple equals banana, but their hashValues (in their own
> types)  don't. What's wrong here? Is that means we shouldn't override
> hashValue in subclass in Swift?

This means you should not override hashValue in this particular way.
If two values are equal, their hash values should be equal.  As long
as your override implementation guarantees this, you can override
hashValue.

You should also understand that the ==(Apple, Apple) and ==(Banana,
Banana) are not overrides for ==(Fruit, Fruit), and they would not be
called through dynamic dispatch when you have, for example, two apples
typed as fruits.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] libswiftCore.dylib was compiled with optimization - stepping may behave oddly;

[Dmitri Gribenko via swift-users]

On Sun, Aug 28, 2016 at 12:51 AM, David Liu  wrote:
> Hi Dimitri
>
> Update, hardcoding the following in the build-script-impl and building
> tool-chain
> -DSWIFT_STDLIB_BUILD_TYPE="Debug"
> -DSWIFT_STDLIB_ASSERTIONS=true
> is working for me.

These two options is what --debug-swift-stdlib expands to.

> But any attempt to build lldb with -l or -lldb fails with the above error. I
> think this unblocks me for now.

+ Sean for LLDB build issues.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Hi, About centos7.1 source compiler error '_swift_stdlib_unicode_strToLower'

[Dmitri Gribenko via swift-users]

On Wed, Aug 10, 2016 at 5:27 PM, SonWa via swift-users
 wrote:
> /usr/bin/ld: stdlib/public/core/linux/x86_64/Swift.o: relocation
> R_X86_64_PC32 against protected symbol `_swift_stdlib_unicode_strToLower'
> can not be used when making a shared object
>
> /usr/bin/ld: final link failed: Wrong value

Hi,

To fix this issue, please install the 'gold' linker.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] C compatible structs

[Dmitri Gribenko via swift-users]

On Mon, Aug 1, 2016 at 4:20 AM, KS Sreeram via swift-users
 wrote:
> Hello
>
> Is it possible to declare Swift structs that have C compatible memory
> layout?

The only supported way to do this is to declare your structs in a C
header that you import in Swift as a module, and #include in your C
libraries.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] C Pointers and Memory

[Dmitri Gribenko via swift-users]

On Fri, Jul 29, 2016 at 12:55 AM, James Campbell  wrote:
> So this:
>
> if let data = someArrayGeneratingFunction() {
>   cFunction(UnsafeMutablePointer(data))
> }
>
> Has issues with the array passed to c getting corrupted, but this doesn't:
>
> let data = someArrayGeneratingFunction()
>
> if let data = data {
>   cFunction(UnsafeMutablePointer(data))
> }

Neither piece of code is guaranteed to work.  (You are just getting
lucky that the second one happens to work.)  Array-to-pointer
conversion only extends the lifetime of the array until the immediate
function call returns.  So after UnsafeMutablePointer(data) returns,
the array can be freed.

Use someArrayGeneratingFunction.withUnsafeMutableBuffer { ... } instead.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] NSData and UnsafePointer

[Dmitri Gribenko via swift-users]

On Sat, Jul 16, 2016 at 1:16 PM, Andrew Trick via swift-users
 wrote:
>
>> On Jul 16, 2016, at 5:28 AM, J.E. Schotsman via swift-users 
>>  wrote:
>>
>> A mysterious bug has got me thinking about using UnsafePointer with 
>> NSData (Swift 2).
>>
>> Is this safe:
>>
>> let data:NSData = …
>> let dataStart = UnsafePointer(data:NSDAta.bytes)
>>
>> myProcessdata1(dataStart,data.length)
>>
>> … (no more references to data)
>
> I don’t know what the recommended idiom is or if the syntax has changed from 
> Swift 2 to 3, but I would do something like this:
>
> withExtendedLifetime(data) {
>   let dataStart = UnsafePointer(data.bytes)
>   myProcessdata1(dataStart,data.length)
> }
>
> UnsafePointers aren’t meant to keep things alive.

This is exactly the reason why Swift 3 changes this API to use the
`data.withUnsafe* {}` idiom.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Parsing binary data

[Dmitri Gribenko via swift-users]

On Fri, Jul 8, 2016 at 12:15 AM, Tino Heth via swift-users
 wrote:
> Hi there!
>
> Some weeks ago I wrote a parser for a binary format, but it's performance was 
> disastrous, and I knew how to easily outperform this first approach with 
> Objective-C by large.
> Now, I'm about to write a different parser, which of course ;-), I'd prefer 
> to code in Swift.
> Working with raw bytes most likely won't ever be a thing where Swift shines, 
> but I guess there are ways to do so without compromising speed… so, are there 
> any established best-practices and things to avoid? Or is it less hassle to 
> go back to C for low-level stuff?

It should be simple: use Array for your data.  Avoid creating
intermediate arrays that hold copies of parts of your data when
possible.  It is OK to slice the array and create ArraySlices.  This
should give you speed close to C.

If you are not satisfied with performance, feel free to post your code
here with some commentary, and someone might look at it and see if
there is any performance advice we could give you.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Checking if an UnsafeMutablePointer is NULL in Swift 3

[Dmitri Gribenko via swift-users]

On Tue, Jul 5, 2016 at 3:40 PM, Vinicius Vendramini via swift-users
 wrote:
> Hi all!
>
> Used to be in Swift 2.x I only had to compare an unsafe pointer (obtained 
> from a C API) to nil to know whether or not it was NULL. After conversion to 
> Swift 3, it seems that isn’t allowed anymore.
>
> I remember watching something about it in WWDC but I can’t remember (or find) 
> the solution anymore. Can someone point me in the right direction?

UnsafePointer is not nullable anymore.  'UnsafePointer?' is
nullable, like any optional.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] LazyCollection.map()

[Dmitri Gribenko via swift-users]

On Tue, Jun 28, 2016 at 3:37 PM, Aaron Bohannon via swift-users
 wrote:
> Does the code below have a well-defined behavior?

It invokes the eager map() that is available on Array.lazy.
Array.lazy is a collection, so it has an eager map() from the
Collection protocol.  The lazy map() does not accept a throwing
closure, so it does not match and the type checker chooses the eager
one.

Arguably, in non-generic context this code should not type check.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Customizing my custom type's appearance in the debugger

[Dmitri Gribenko via swift-users]

On Sun, Jun 26, 2016 at 5:03 PM, Tim Vermeulen  wrote:
> I already did that, sorry for not providing any code. Take this as an
> example:
>
> public struct Wrapper {
>
> private var elements: [Element]
>
> public init(_ sequence:
> S) {
> elements = [Element](sequence)
> }
>
> }
>
> extension Wrapper: Collection {
>
> public var startIndex: Int { return elements.startIndex }
> public var endIndex: Int { return elements.endIndex }
>
> public func index(after index: Int) -> Int {
> return index + 1
> }
>
> public subscript(position: Int) -> Element {
> return elements[position]
> }
>
> }
>
> extension Wrapper: CustomReflectable {
>
> public var customMirror: Mirror {
> return Mirror(self, unlabeledChildren: self, displayStyle:
> .collection)
> }
>
> }
>
> If I debug an instance of this Wrapper type, then Xcode’s Variables View
> will show
>
> ▿ wrapper
>   ▿ elements = x values
> [0] = 0
> [1] = …

I see.  I'm not sure there's a way to hide anything from Xcode's variables view.

+Enrico.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Customizing my custom type's appearance in the debugger

[Dmitri Gribenko via swift-users]

On Fri, Jun 24, 2016 at 3:53 PM, Tim Vermeulen via swift-users
 wrote:
> I’ve implemented a linked list. Now I’d like to be able to view the elements 
> of a linked list in the debugger just like with an array. In the debugger, an 
> array is represented like this:
>
> [0] = the first element
> [1] = the second element
> etc
>
> I wonder if I can do the same for my linked list. I already implemented 
> CustomReflectable, so the code `dump(myLinkedList)` shows this in the console:
>
> 3 elements
>   - first element
>   - second elements
>   - third element
>
> I thought this would also change the appearance of my linked list in the 
> debugger, but unfortunately it’s unchanged. Is there a way to do what I’m 
> trying to do?

Try setting "displayStyle: .collection" when you call the Mirror initializer.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] AnySequence and type erasure

[Dmitri Gribenko via swift-users]

On Thu, Jun 23, 2016 at 2:12 AM, Svein Halvor Halvorsen
 wrote:
> 2016-06-18 10:23 GMT+02:00 Dmitri Gribenko :
>>
>> On Fri, Jun 17, 2016 at 12:37 PM, Svein Halvor Halvorsen
>>  wrote:
>> > Ok. Good to hear that I'm not too far off :)
>> >
>> > Can you provide me with an example of a sequence type or two that has
>> > some
>> > map or other function that would benefit from an optimized wrapper? Or:
>> > under what circumstances would the stdlib implementation outperform
>> > mine?
>>
>> Compare the default implementations of map() for Sequence and
>> Collection.  In the Sequence case, we don't know the size of the
>> resulting array, so we have to grow the resulting array as we pull the
>> elements from the sequence.  In the case of running Collection.map()
>> we know the final size from the count property.  In the case of Array
>> we can do even better and eliminate a check (the _expectEnd()
>> call).  However, certain collections where calculating the number of
>> elements might be expensive, can opt into the Sequence behavior (e.g.,
>> various string views); this is up to the designer of the specific
>> collection.
>
>
> Is this a problem in reality? The map() on Sequence uses underestimatedCount
> to reserve capacity, and if the sequence wraps a collection type,
> underestimatedCount is presumably O(1) and returns the same value as count,
> non?

You can't call '.count' on a Sequence without potentially consuming
the sequence.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] AnySequence and type erasure

[Dmitri Gribenko via swift-users]

On Fri, Jun 17, 2016 at 12:37 PM, Svein Halvor Halvorsen
 wrote:
> Ok. Good to hear that I'm not too far off :)
>
> Can you provide me with an example of a sequence type or two that has some
> map or other function that would benefit from an optimized wrapper? Or:
> under what circumstances would the stdlib implementation outperform mine?

Compare the default implementations of map() for Sequence and
Collection.  In the Sequence case, we don't know the size of the
resulting array, so we have to grow the resulting array as we pull the
elements from the sequence.  In the case of running Collection.map()
we know the final size from the count property.  In the case of Array
we can do even better and eliminate a check (the _expectEnd()
call).  However, certain collections where calculating the number of
elements might be expensive, can opt into the Sequence behavior (e.g.,
various string views); this is up to the designer of the specific
collection.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] AnySequence and type erasure

[Dmitri Gribenko via swift-users]

On Fri, Jun 17, 2016 at 1:39 AM, Svein Halvor Halvorsen via
swift-users  wrote:
> I'm sure people here know about the problem that AnySequence, AnyGenerator,
> etc solves.
> In Swift, a protocol can have an associated type, which is kinda like
> generics, but you cannot declare a variable like this:
>
> let sequence: SequenceType
>
> If you want a sequence, any sequence, over ints you need to wrap the
> protocol in a new concrete, generic type, AnySequence that itself
> implements the protocol SequenceType, and where the associated type Element
> is equal to the generic type T.
>
> The standard library does this. And, like many others, I have tried to
> implement this for my self, to try to better understand the problem, and I
> expected that I would end up with a design very similar to what the standard
> library does. However, I have not seen the need for the complex boxing
> mechanism. I'm probably misunderstanding something, though.
>
> Can someone please look at this code, and give me constructive feedback? Is
> this a novel and working solution, or am I missing something?:

Hi,

Your design should work, but it won't provide optimal performance.
Sequence has a lot of requirements that can be customized by the
conforming type (e.g., map()).  We need to forward those to the
original type to get the best performance.

While you can create a closure for each of the forwarded methods,
let's say n in total, it is n times more wasteful compared to using
just a single reference like the standard library does.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] build-script error

[Dmitri Gribenko via swift-users]

Hi Jeff,

Please take a look at these pull requests and commits to get a general
idea of what it takes to port Swift to a new platform:

https://github.com/apple/swift/pull/2541
https://github.com/apple/swift/pull/979
https://github.com/apple/swift/commit/83751888c73de2504cbfa87906adf7c526d6fc65

Dmitri

On Sat, Jun 11, 2016 at 4:36 AM, Jeff Ramsey  wrote:
> Dmitri,
>
> Can you point me to the general areas that would need changes for 32-bit and 
> I'll look to see what would be needed?  Thanks.
>
> Jeff
>
>> On Jun 11, 2016, at 12:31 AM, Dmitri Gribenko  wrote:
>>
>> Hi Jeff,
>>
>> Karl is right.  Swift is not ported to 32-bit Linux right now --
>> sorry!  We would welcome contributions from the community to fill this
>> gap.  I would be happy to review the patches and discuss any issues
>> that come up.
>>
>> Dmitri
>>
>>> On Fri, Jun 10, 2016 at 8:06 PM, Karl  wrote:
>>> i686 is a 32-bit system, right? We don’t support Intel 32-bit on Linux
>>> (yet?). The only Intel Linux target is x86_64.
>>>
>>>
>>> On 10 Jun 2016, at 20:18, Jeff Ramsey via swift-users
>>>  wrote:
>>>
>>> Here you go Dmitri.  It's an older Dell 1501 that was given to me; I wiped
>>> it and put Ubuntu on it.  Thanks.
>>>
>>> Python 2.7.6 (default, Jun 22 2015, 18:00:18)
>>> [GCC 4.8.2] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>> import platform
>> print(platform.system())
>>> Linux
>> print(platform.machine())
>>> i686
>>
>>>
>>> Here's some additional information if it's useful:
>>>
>>> ~/swift$ lsb_release -a
>>> No LSB modules are available.
>>> Distributor ID:Ubuntu
>>> Description:Ubuntu 14.04.3 LTS
>>> Release:14.04
>>> Codename:trusty
>>>
>>> ~/swift$ uname -a
>>> Linux Inspiron-1501 3.13.0-74-generic #118-Ubuntu SMP Thu Dec 17 22:52:02
>>> UTC 2015 i686 athlon i686 GNU/Linux
>>>
>>>
>>>
>>> On Fri, Jun 10, 2016 at 12:31 PM, Dmitri Gribenko 
>>> wrote:

 On Fri, Jun 10, 2016 at 9:14 AM, Jeff Ramsey via swift-users
  wrote:
> I followed directions here to clone the compiler source and build it on
> Ubuntu 14.04:
>
> https://github.com/apple/swift/blob/master/README.md

 Hi Jeff,

 Which architecture are you running on?

 Could you run "python" in the terminal, type the following script, and
 send me the output?

 import platform
 print(platform.system())
 print(platform.machine())

 Dmitri

 --
 main(i,j){for(i=2;;i++){for(j=2;j*/
>>>
>>>
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>
>>>
>>
>>
>>
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko */



-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] UnsafeMutablePointer vs. UnsafeMutablePointer

[Dmitri Gribenko via swift-users]

On Sat, May 21, 2016 at 2:15 AM, Adrian Zubarev via swift-users
 wrote:
> So basically if I do something like this I should be on the safe side:

Yes, this code is safe.  If you just want to store a contiguous buffer
of elements of the same type, you should consider using Array.  It has
methods that will allow you to operate on the unsafe pointer to the
memory if you need that for speed, but it will do the memory
management for you.

> Does the UnsafeMutablePointer reserves me a safe portion of memory (by safe
> I mean which isn’t used by anyone at the time I will start using it)?

Yes, you will become a unique owner of the newly allocated chunk of
memory.  (Same as malloc() in C.)

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] function advancedBy() bugs

[Dmitri Gribenko via swift-users]

On Tue, May 17, 2016 at 5:46 AM, zh ao via swift-users
 wrote:
> It seams that I encountered bugs in function advancedBy().
>
> do {
> var str = "abcdefg"
> var range = str.startIndex.. str += "hijklmn"
> range.endIndex = str.endIndex // 0..<14
> let index = range.startIndex.advancedBy(10)
> //fatal error: cannot increment endIndex
> }

Hi,

Thank you for the report.  To me, this issue looks the same as
https://bugs.swift.org/browse/SR-1487.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SubSequence Index bug in generic functions?

[Dmitri Gribenko via swift-users]

On Wed, May 11, 2016 at 1:48 PM, Hooman Mehr via swift-users
 wrote:
> The reason this is appearing here before filing a radar is getting a quick
> feedback as I have been assuming this is the expected behavior but Nate Cook
> told me otherwise. See this thread for the initial discussion that lead to
> this.

Hi Hooman,

This is a bug in String indices.  Could you file it, we will look into it.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Guarding against an empty sequence

[Dmitri Gribenko via swift-users]

On Mon, May 9, 2016 at 8:21 AM, Shane S via swift-users
 wrote:
> On May 9, 2016, at 6:18 AM, Adriano Ferreira 
> wrote:
>
> So, I thought about “underestimatedCount” but was not sure how to use it
> properly.
>
>
> `guard self.underestimateCount > 0 else {return false}`

`underestimateCount` is what it says, an underestimate.  A non-empty
sequence can return 0.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Range.count can abort

[Dmitri Gribenko via swift-users]

On Sat, Apr 16, 2016 at 8:29 AM,   wrote:
> Is there any reason that Distance has to be a simple Int? Since it’s defined
> per-type, UInt64 could use a custom struct without impacting the performance
> of other types:

It needs to be a signed integer.  And a signed integer needs a
distance type itself.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Range.count can abort

[Dmitri Gribenko via swift-users]

On Fri, Apr 15, 2016 at 4:41 PM, Jens Alfke  wrote:
>
>
> --Jens [via iPhone]
>
>> On Apr 15, 2016, at 4:26 PM, Dmitri Gribenko  wrote:
>>
>> The distance is signed so that we can represent negative distances.
>> r.distance(from:to:) should be able to measure distances backwards.
>
> Yeah, makes sense in general, just not for this particular case...
>>
>> We are aware of this issue, but we don't know of a good solution.
>> We'd appreciate your suggestions.
>
> Add Int128! ;-)
>
> Ok, maybe that just pushes the problem further down the road.

Indeed.

> How about making Distance be Double? ;-)

Double only has 53 bits of precision.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Generic factory method and type inference

[Dmitri Gribenko via swift-users]

On Thu, Mar 17, 2016 at 6:58 AM, Rudolf Adamkovič  wrote:
> How come I can’t call zip without explicitly specifying return type?
>
> // ERROR: Cannot invoke `zip` with an argument list of type `(Int, Int)`
> let y = Something.zip(1, 2)

The compiler can't infer T from your call.  T and (A, B) are three
separate type parameters.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Collection underestimatedCount() does _?

[Dmitri Gribenko via swift-users]

On Fri, Mar 18, 2016 at 10:53 PM, Will Stanton via swift-users
 wrote:
> I might have missed something since a lot of the results are for tests 
> 
> But why would `underestimatedCount` ever be used instead of `count`? Don’t 
> most collections have O(1) `count` anyway?

Hi Will,

This API comes from Sequence, which does not have a count that you can
inspect without possibly consuming the sequence.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] REPL failed

[Dmitri Gribenko via swift-users]

On Sun, Dec 20, 2015 at 12:03 PM, Daniel Dunbar  wrote:
>
> On Dec 10, 2015, at 11:07 AM, Dmitri Gribenko  wrote:
>
> On Thu, Dec 10, 2015 at 9:59 AM, Daniel Dunbar 
> wrote:
>
> Actually, I am retracting this suggestion in favor of what I think is a
> better one:
>
> What if we change the build process to build up a "composed package" as part
> of the regular build. We would clear this at the start of each build, and
> then build up the installed compiler + libraries + package manager as each
> project completed its build (basically just using the same install logic
> into a side location).
>
> This has a number of benefits:
>
> - At the end of the build, we have a "build//bin" directory which
> has a functioning compiler.
> - Each project in the chain can use the composed build to work with. So for
> example, the package manager can build with the compiler + xctest as they
> are expected to look in a package. This would reduce some complexity in our
> build process, and be more maintainable.
> - This solution scales better if/when we add more projects.
> - This solution also lets the build easily sub in an "prebuilt package" into
> the build process (it just means pointing at a different composed package).
>
> Thoughts?
>
>
> My concern is that copying files around will significantly increase
> the build time for everyone because of I/O.  Debug builds of Swift are
> quite large (> 700 Mb IIRC).
>
>
> My thought here was to use rsync and its options for creating hard links
> where possible. This makes the copying very cheap...

How would you implement it in practice?  CMake does not know how to
use rsync for its 'install' target, IIRC.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Cross Compiling Swift for Bare Metal?

[Dmitri Gribenko via swift-users]

On Sat, Dec 19, 2015 at 6:53 PM, Chaitanya Mannem via swift-users <
swift-users@swift.org> wrote:

> Hi,
>
>
> I wanted to know if it is possible to compile swift code for bare metal. I
> know there is a runtime but does swift depend on it to execute even if I
> don't use those features?, can I disable them somehow. I was hoping that
> since you can produce LLVM Bytecode that you can cross compile using the
> arm-none-eabi toolchain for an embedded use-case (
> http://www.ti.com/tool/ek-tm4c123gxl). Please tell me there's hope, I
> don't want to use C++  :(
>

It is a goal of Swift to be a systems programming language, but nobody has
yet compiled a program using Swift for a bare-metal target, so a
significant amount of work would be required.

The Swift runtime is required to support basic features such as object
allocation, casts and generics, so you can't just omit it.

Regarding the microcontroller that you referenced, I think it would be an
overly ambitious goal to try to make everything work with 256 Kb of flash
and 32 Kb of RAM.  I would recommend to start with a more powerful
bare-metal target, and get things working without an OS and memory
protection, measure RAM and flash consumption, and try to fit everything
into a smaller MCU.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Need better name, want to hide generator

[Dmitri Gribenko via swift-users]

On Fri, Dec 18, 2015 at 1:22 PM, Erica Sadun via swift-users <
swift-users@swift.org> wrote:

> 2. Is there a way to internalize the generator and not make it public? I'd
> ideally like to hide all details except the fact that this is a sequence of
> (Int, Int)
>

You can use AnySequence and AnyGenerator, but they come at a cost of
dynamic dispatch for every call.  In this case, if you want this component
to be suitable for performance-critical code, I would suggest to avoid them
for now.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Using NSObject subclass instance as key in Dictionary

[Dmitri Gribenko via swift-users]

On Thu, Dec 17, 2015 at 2:17 PM, Etan Kissling via swift-users <
swift-users@swift.org> wrote:

> I want to use instances of a custom class as Dictionary key.
> This requires the class to conform to Hashable.
>
> func ==(lhs: KeyType1, rhs: KeyType1) -> Bool { return lhs.id == rhs.id }
>
> final class KeyType1: Hashable, CustomStringConvertible {
> let id: String
> init(id: String) { self.id = id }
> var hashValue: Int { return id.hashValue }
> var description: String { return id }
> }
>
>
> Now I can use KeyType1 instances as key in Dictionary.
>
> var collection1 = [KeyType1(id: "foo") : NSObject()]
>
>
> Testing works fine:
>
> let key = collection1.first!.0
> print("Key stored in collection: \(unsafeAddressOf(key)) -- \(
> key)")
>
>
> let keyCopy = KeyType1(id: key.id)
> print("Key copy: \(unsafeAddressOf(keyCopy))
> -- \(keyCopy)")
>
>
> print("  Keys equal: \(key == keyCopy)")
> print("   Hash values equal: \(key.hashValue == keyCopy.
> hashValue)")
> print(" Collection has item for key: \(collection1[key] != nil)")
> print("Collection has item for key copy: \(collection1[keyCopy] != nil
> )")
>
> *Key stored in collection: 0x60843d80 -- foo*
> *Key copy: 0x608440b0 -- foo*
> *  Keys equal: true*
> *   Hash values equal: true*
> * Collection has item for key: true*
> *Collection has item for key copy: true*
>
>
>
> Next, I repeat the same set up -- but this time KeyType is a descendant of
> NSObject.
>
> func ==(lhs: KeyType2, rhs: KeyType2) -> Bool { return lhs.id == rhs.id }
>
> final class KeyType2: NSObject { // NSObject conforms to Hashable and
> CustomStringConvertible.
> let id: String
> init(id: String) { self.id = id; super.init() }
> override var hashValue: Int { return id.hashValue }
> override var description: String { return id }
> }
>
> Again, I create a Dictionary based on this key class.
>
> var collection2 = [KeyType2(id: "foo") : NSObject()]
>
> Using the same tests, they fail now.
>
> let key = collection2.first!.0
> print("Key stored in collection: \(unsafeAddressOf(key)) -- \(
> key)")
>
> let keyCopy = KeyType2(id: key.id)
> print("Key copy: \(unsafeAddressOf(keyCopy))
> -- \(keyCopy)")
>
> print("  Keys equal: \(key == keyCopy)")
> print("   Hash values equal: \(key.hashValue == keyCopy.
> hashValue)")
> print(" Collection has item for key: \(collection2[key] != nil)")
> print("Collection has item for key copy: \(collection2[keyCopy] != nil
> )")
>
> *Key stored in collection: 0x60844080 -- foo*
> *Key copy: 0x608440e0 -- foo*
> *  Keys equal: true*
> *   Hash values equal: true*
> * Collection has item for key: true*
> *Collection has item for key copy: false*
>
>
> What am I missing here?
>

The == overload in the second case is not the one that gets put into the
protocol witness table.  When you call == on two instances of your type,
upcast to NSObject, the isEqual() method is called.

We are aware of this issue and it will be fixed when we move operators into
types.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift is building from source, failing tests.

[Dmitri Gribenko via swift-users]

On Fri, Dec 11, 2015 at 11:12 AM, Dylan Brown via swift-users <
swift-users@swift.org> wrote:

> Hello! When running `utils/build-script --clean -t`, I'm able to complete
> the build but it regularly fails the same 4/6 tests. Also, check-swift and
> check-swift-validation are not found in the build directory alongside
> Ninja-DebugAssert.
> I've been working at this for a while, and I'm not sure where to look
> next. Any ideas what could be going wrong?
>
> Thanks!
> Dylan
>
>   Python 2.7.10
>

You probably have Python 3.5 installed.  Cmark tests are incompatible with
that revision.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users