Re: [swift-dev] What can you change in a fixed-contents struct?

[Slava Pestov via swift-dev]

> On Sep 6, 2017, at 7:57 PM, Brent Royal-Gordon via swift-dev 
>  wrote:
> 
>> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev > > wrote:
>> 
>> Now, we don't plan to stick to C's layout for structs, even fixed-contents 
>> structs. We'd really like users to not worry about manually packing things 
>> into trailing alignment space. But we still need a way to lay out fields 
>> consistently; if you have two stored properties with the same type, one of 
>> them has to go first. There are two ways to do this: sort by name, and sort 
>> by declaration order. That means we can either allow reordering or allow 
>> renaming, but not both. Which do people think is more important?
> 
> This is going against the grain, but I think we should order by name and 
> therefore allow reordering, but not renaming. If an API is public, renaming 
> is obviously going to be source-breaking and could easily be ABI-breaking; I 
> don't think it's that hard to explain that renaming can also be ABI-breaking 
> when you've declared your type's layout is part of your module's ABI.

However, @fixedContents structs can also contain private stored properties. 
Renaming a private property is not source-breaking (but if we sort by name when 
performing layout, it will be ABI breaking).

> As for the keyword…maybe `public(layout)` or `public(storage)`? People are 
> familiar with the idea that you have to be careful when you change something 
> that's public, so it wouldn't be surprising that a type with a public layout 
> would be sensitive to changes to its memory layout.

I’m hesitant to use a keyword rather than an @attribute for this, because (for 
the most part) attributes don’t change the language semantics of a declaration, 
only its implementation (of course there are exceptions, like @objc which 
introduces restrictions, etc).

Slava

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] What can you change in a fixed-contents struct?

[Brent Royal-Gordon via swift-dev]

> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev  
> wrote:
> 
> Now, we don't plan to stick to C's layout for structs, even fixed-contents 
> structs. We'd really like users to not worry about manually packing things 
> into trailing alignment space. But we still need a way to lay out fields 
> consistently; if you have two stored properties with the same type, one of 
> them has to go first. There are two ways to do this: sort by name, and sort 
> by declaration order. That means we can either allow reordering or allow 
> renaming, but not both. Which do people think is more important?

This is going against the grain, but I think we should order by name and 
therefore allow reordering, but not renaming. If an API is public, renaming is 
obviously going to be source-breaking and could easily be ABI-breaking; I don't 
think it's that hard to explain that renaming can also be ABI-breaking when 
you've declared your type's layout is part of your module's ABI. And we can 
always introduce a renaming attribute that causes the property to be laid out 
and linked by its old name:

@fixedContents struct Foo {
@renamed(from: x, in: iOS 14)
var xCount: Int

@renamed(from: y, in: iOS 14)
var yAverage: Double

@renamed(from: z, in: iOS 14)
var zIdentifier: String
}

We could detect properties appearing and disappearing in our compatibility 
checker tool and help people add the missing attributes. We could provide 
fix-its for renames of public APIs. We could use the name `_` to allow a type 
to reserve space for future expansion, or remove a property that is no longer 
used. We could add a syntax to `@renamed` that permits the space used by old 
properties to be subdivided into new ones. And we can always add ways to 
manually control the layout of a type in future versions of Swift; they would 
be usable both with and without `@fixedContents`, and would be orthogonal to 
`@fixedContents`.

(In theory, we could do this with `@available`, but its current renaming 
support requires a dummy declaration.)

As for the keyword…maybe `public(layout)` or `public(storage)`? People are 
familiar with the idea that you have to be careful when you change something 
that's public, so it wouldn't be surprising that a type with a public layout 
would be sensitive to changes to its memory layout.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-dev] What can you change in a fixed-contents struct?

[Slava Pestov via swift-dev]

> On Sep 6, 2017, at 11:09 AM, David Zarzycki via swift-dev 
>  wrote:
> 
> I see. Would “@fixedSize” or “@abi(size)” be better names? In other words, 
> the developer promises that whatever size the struct is now, it will be that 
> way forever?
> 
> Also, wouldn’t the Pair example below require that ‘A’ also be 
> @fixedContents? Otherwise what does @fixedContents mean if the elements 
> aren’t fixed?

We don’t require ‘transitive’ fragility with generic value types containing 
other types. Otherwise, Optional would have to require that T is 
fixedContents, which is too restrictive.

Slava

> 
> Dave
> 
> 
>> On Sep 6, 2017, at 13:44, Jordan Rose > > wrote:
>> 
>> I don't think that's the right way to think about it either. It's purely an 
>> optimization tool to say "I won't add anything else to this struct", which 
>> means the compiler can avoid indirection when manipulating the struct across 
>> module boundaries. We could implement it with dynamic offset symbols and 
>> still see some benefit, but in this case we really ought to be able to get 
>> all the way to C-level performance.
>> 
>> The name hasn't been formalized; this will all go through swift-evolution at 
>> some point. We thought about "fixed-layout" in the past, but that doesn't 
>> have the right connotations for something like Pair:
>> 
>> @fixedContents
>> public struct Pair {
>>   public var first: A
>>   public var second: A
>>   public init(first: A, second: A) { … }
>> }
>> 
>> This has known properties, but the layout depends on the generic argument, 
>> and if the generic argument is itself a type with unknown size then the 
>> actual layout won't be known until runtime.
>> 
>> Jordan
>> 
>> 
>>> On Sep 6, 2017, at 10:40, David Zarzycki >> > wrote:
>>> 
>>> Ah, now that I see the CGPoint example, I understand. Thanks! Ya, the 
>>> “hard” user-experience model I brought up feels wrong for CGPoint, etc. 
>>> (For non-Apple people, CGPoint is a struct of two doubles on 64-bit 
>>> machines add two floats on 32-bit machines.)
>>> 
>>> It wasn’t obvious to me from context that @fixedContents wasn’t / isn’t for 
>>> people trying to design a comprehensive ABI (disk, wire, etc), but just the 
>>> machine specific in memory ABI. I wish the name was better, but nothing 
>>> better seems obvious. (“@inMemoryABI”?)
>>> 
>>> Dave
>>> 
 On Sep 6, 2017, at 13:11, Jordan Rose >>> > wrote:
 
 I'd be okay with allowing the ABI attributes to control ordering, but I 
 would definitely not require them on every fixed-contents struct. We hope 
 making a struct fixed-contents isn't something people have to do too 
 often, but we don't want to drop them all the way into "hard" land when 
 they do it. That is, "CGPoint" can't already be "hard mode".
 
 Jordan
 
 
> On Sep 6, 2017, at 05:13, David Zarzycki  > wrote:
> 
> Hi Jordan,
> 
> I really doubt that “belt and suspenders” ABI attributes would drive 
> people to C, but reasonable people can certainly disagree on that.
> 
> Bertrand, when he was at Apple, used to say that “easy things should be 
> easy, and hard things should be possible”.
> 
> I think ABI related attributes fall into the latter category. In 
> particular, I think that trying to make ABI attributes too convenient 
> only does programmers a disservice in the long run because most 
> programmers aren't experts, and the cost of ignorance is huge when trying 
> to do ABI design.
> 
> With these thoughts in mind, I think that is reasonable for the language 
> to say: “If you want explicit control over a dimension of ABI decisions, 
> then you must deal with all of the associated complexity. Here is a 
> pointer to the documentation on dimension X that you were/are trying to 
> explicitly manage. If that is ’too hard’ for you, then you probably 
> shouldn’t be locking down this dimension of complexity yet.”
> 
> Dave
> 
>> On Sep 5, 2017, at 20:11, Jordan Rose > > wrote:
>> 
>> Hm. This is definitely an option, but I don't think it's really an 
>> acceptable user experience. This feels like it'll drive people all the 
>> way to declaring their types in C because Swift makes it too hard.
>> 
>> We do expect to have a tool to diff old and new modules at some point, 
>> but we could do something even simpler here: make a public symbol with 
>> the struct's layout in its name. That way, even 'nm' can tell if the 
>> symbol disappears. (Of course, public symbols do have a small cost, 
>> since this might not actually be the best idea.)
>> 
>> Another idea would be to restrict @fixedContents to require that all 
>> stored properties appear contiguously in the struct, possibly even 
>> pinned

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #425

[Arnold Schwaighofer via swift-dev]

For example, an  the same failure occurred earlier here:

https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/422/console
 


> On Sep 6, 2017, at 12:54 PM, Arnold Schwaighofer  
> wrote:
> 
> Cannot be related to my commit. I did however see this test failing 
> intermittently.
> 
> 
>> On Sep 6, 2017, at 12:48 PM, Mishal Shah > > wrote:
>> 
>> Test Case 'TestURLSession.test_concurrentRequests' started at 2017-09-06 
>> 19:43:55.444
>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script-impl:
>>  line 262: 25147 Segmentation fault  "$@“
>> 
>> Thanks,
>> Mishal Shah
>> 
>>> On Sep 6, 2017, at 12:43 PM, no-re...@swift.org  
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#425]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/425/ 
>>> 
>>> Project:oss-swift-incremental-RA-linux-ubuntu-16_10
>>> Date of build:  Wed, 06 Sep 2017 14:30:20 -0500
>>> Build duration: 14 min
>>> Tests:
>>> 
>>> Name: Swift(linux-x86_64)
>>> Failed: 0 test(s), Passed: 9867 test(s), Total: 9867 test(s)
>>> Name: Swift-Unit
>>> Failed: 0 test(s), Passed: 443 test(s), Total: 443 test(s)
>>> 
>>> Changes
>>> 
>>> Commit efceb8acc18c40af70649db8684266933591b35a by aschwaighofer:
>>> Run optimize for size tests (Osize) on the bots
>>> 
>>> edit: utils/build-presets.ini
>> 
> 

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #425

[Arnold Schwaighofer via swift-dev]

Cannot be related to my commit. I did however see this test failing 
intermittently.


> On Sep 6, 2017, at 12:48 PM, Mishal Shah  wrote:
> 
> Test Case 'TestURLSession.test_concurrentRequests' started at 2017-09-06 
> 19:43:55.444
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script-impl:
>  line 262: 25147 Segmentation fault  "$@“
> 
> Thanks,
> Mishal Shah
> 
>> On Sep 6, 2017, at 12:43 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#425]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/425/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Wed, 06 Sep 2017 14:30:20 -0500
>> Build duration:  14 min
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 9867 test(s), Total: 9867 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 443 test(s), Total: 443 test(s)
>> 
>> Changes
>> 
>> Commit efceb8acc18c40af70649db8684266933591b35a by aschwaighofer:
>> Run optimize for size tests (Osize) on the bots
>> 
>> edit: utils/build-presets.ini
> 

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #425

[Mishal Shah via swift-dev]

Test Case 'TestURLSession.test_concurrentRequests' started at 2017-09-06 
19:43:55.444
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script-impl:
 line 262: 25147 Segmentation fault  "$@“

Thanks,
Mishal Shah

> On Sep 6, 2017, at 12:43 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#425]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/425/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Wed, 06 Sep 2017 14:30:20 -0500
> Build duration:   14 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9867 test(s), Total: 9867 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 443 test(s), Total: 443 test(s)
> 
> Changes
> 
> Commit efceb8acc18c40af70649db8684266933591b35a by aschwaighofer:
> Run optimize for size tests (Osize) on the bots
> 
> edit: utils/build-presets.ini

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

Re: [swift-dev] Swift build on ppc64le platform

[John McCall via swift-dev]

> On Sep 6, 2017, at 3:28 AM, Meghali Dhoble  wrote:
> Thanks John, for the response.
> We have a patch added already for ppc64 support at llvm, however still the 
> failures seen,
> 
Did you change Clang?

John.
> I will try to opt for 2nd option and see if that helps.
> 
> Thanks,
> Meghali
> 
> John McCall ---08/28/2017 09:59:28 PM---> On Aug 28, 2017, at 
> 9:08 AM, Meghali Dhoble via swift-dev  wrote: > Hi,
> 
> From: John McCall 
> To: Meghali Dhoble 
> Cc: swift-dev , Graydon Hoare 
> Date: 08/28/2017 09:59 PM
> Subject: Re: [swift-dev] Swift build on ppc64le platform
> Sent by: rjmcc...@apple.com
> 
> 
> 
> On Aug 28, 2017, at 9:08 AM, Meghali Dhoble via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> Hi, 
> I have been working towards getting the swift source code built on my power 
> (ppc64le) platform on Ubuntu16.04 OS. 
> I am observing build issues and looking for some help here. Please redirect 
> me if this is not the right place for these questions.
> 
> I would like to understand the pre-requisites and the hardware configurations 
> required to build this language. 
> The error I am getting look like memory issues as the process is being killed 
> abruptly. I am attaching the log herewith for reference.
> 
> I don't see anything like that in the log. It looks like an ordinary compiler 
> error relating to our custom calling convention.
> 
> You need to either
> 1. implement swiftcc in LLVM's ppc64 backend and then teach Clang that it's 
> legal there or
> 2. configure Swift to not try to use it.
> 
> In the short term, I suspect that (2) is the right approach. Graydon was at 
> least thinking about doing some work recently that would be aimed at making 
> it easier to do this kind of configuration; CC'ing him explicitly to see if 
> there's been progress there.
> 
> John.
> 

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

Re: [swift-dev] What can you change in a fixed-contents struct?

[David Zarzycki via swift-dev]

Hi Jordan,

Okay, I just read the Library Evolution section about @fixedContents. Ya, the 
name of this attribute is difficult due to the collection of goals and subtle 
implications. I worry that others will find it difficult too, no matter what 
the name. :-/

I skimmed the rest of the document looking for any kind of list or graphic 
showing the spectrum of fragility tradeoffs (from fully non-fragile to fully 
fragile), but I didn’t see anything. Am I missing something? I’m trying to see 
the overarching vision of how all of these attributes fit and work together, 
and how a user would/should approach giving up some resiliency to gain 
efficiency.

Dave


> On Sep 6, 2017, at 14:18, Jordan Rose  wrote:
> 
> That's exactly why neither of those names are correct. The annotation we're 
> describing here means "the stored properties of this struct will not change, 
> please optimize". That gives us the actual fully-specified layout 
> optimizations when the contents happen to be non-generic and similarly 
> annotated, while still being useful for cases where the members are generic 
> or opaque. (For example, if a client library makes a Pair, the 
> client now fully understands the struct layout even if other libraries don't.)
> 
> All of this comes from the Library Evolution 
> 
>  plan, which mentions (in a corner) more low-level promises 
> 
>  like "trivial". But these are things that I'd consider "hard mode" and not 
> worthy of focus.
> 
> Jordan
> 
> 
>> On Sep 6, 2017, at 11:08, David Zarzycki > > wrote:
>> 
>> I see. Would “@fixedSize” or “@abi(size)” be better names? In other words, 
>> the developer promises that whatever size the struct is now, it will be that 
>> way forever?
>> 
>> Also, wouldn’t the Pair example below require that ‘A’ also be 
>> @fixedContents? Otherwise what does @fixedContents mean if the elements 
>> aren’t fixed?
>> 
>> Dave
>> 
>> 
>>> On Sep 6, 2017, at 13:44, Jordan Rose >> > wrote:
>>> 
>>> I don't think that's the right way to think about it either. It's purely an 
>>> optimization tool to say "I won't add anything else to this struct", which 
>>> means the compiler can avoid indirection when manipulating the struct 
>>> across module boundaries. We could implement it with dynamic offset symbols 
>>> and still see some benefit, but in this case we really ought to be able to 
>>> get all the way to C-level performance.
>>> 
>>> The name hasn't been formalized; this will all go through swift-evolution 
>>> at some point. We thought about "fixed-layout" in the past, but that 
>>> doesn't have the right connotations for something like Pair:
>>> 
>>> @fixedContents
>>> public struct Pair {
>>>   public var first: A
>>>   public var second: A
>>>   public init(first: A, second: A) { … }
>>> }
>>> 
>>> This has known properties, but the layout depends on the generic argument, 
>>> and if the generic argument is itself a type with unknown size then the 
>>> actual layout won't be known until runtime.
>>> 
>>> Jordan
>>> 
>>> 
 On Sep 6, 2017, at 10:40, David Zarzycki >>> > wrote:
 
 Ah, now that I see the CGPoint example, I understand. Thanks! Ya, the 
 “hard” user-experience model I brought up feels wrong for CGPoint, etc. 
 (For non-Apple people, CGPoint is a struct of two doubles on 64-bit 
 machines add two floats on 32-bit machines.)
 
 It wasn’t obvious to me from context that @fixedContents wasn’t / isn’t 
 for people trying to design a comprehensive ABI (disk, wire, etc), but 
 just the machine specific in memory ABI. I wish the name was better, but 
 nothing better seems obvious. (“@inMemoryABI”?)
 
 Dave
 
> On Sep 6, 2017, at 13:11, Jordan Rose  > wrote:
> 
> I'd be okay with allowing the ABI attributes to control ordering, but I 
> would definitely not require them on every fixed-contents struct. We hope 
> making a struct fixed-contents isn't something people have to do too 
> often, but we don't want to drop them all the way into "hard" land when 
> they do it. That is, "CGPoint" can't already be "hard mode".
> 
> Jordan
> 
> 
>> On Sep 6, 2017, at 05:13, David Zarzycki > > wrote:
>> 
>> Hi Jordan,
>> 
>> I really doubt that “belt and suspenders” ABI attributes would drive 
>> people to C, but reasonable people can certainly disagree on that.
>> 
>> Bertrand, when he was at Apple, used to say that “easy things should be 
>> easy, and hard things should be possible”.
>> 
>> I think ABI related attributes fall into the latter category. In 
>> particular, I think that trying to make ABI attributes too convenient

Re: [swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

That's exactly why neither of those names are correct. The annotation we're 
describing here means "the stored properties of this struct will not change, 
please optimize". That gives us the actual fully-specified layout optimizations 
when the contents happen to be non-generic and similarly annotated, while still 
being useful for cases where the members are generic or opaque. (For example, 
if a client library makes a Pair, the client now fully understands 
the struct layout even if other libraries don't.)

All of this comes from the Library Evolution 
 
plan, which mentions (in a corner) more low-level promises 

 like "trivial". But these are things that I'd consider "hard mode" and not 
worthy of focus.

Jordan


> On Sep 6, 2017, at 11:08, David Zarzycki  wrote:
> 
> I see. Would “@fixedSize” or “@abi(size)” be better names? In other words, 
> the developer promises that whatever size the struct is now, it will be that 
> way forever?
> 
> Also, wouldn’t the Pair example below require that ‘A’ also be 
> @fixedContents? Otherwise what does @fixedContents mean if the elements 
> aren’t fixed?
> 
> Dave
> 
> 
>> On Sep 6, 2017, at 13:44, Jordan Rose > > wrote:
>> 
>> I don't think that's the right way to think about it either. It's purely an 
>> optimization tool to say "I won't add anything else to this struct", which 
>> means the compiler can avoid indirection when manipulating the struct across 
>> module boundaries. We could implement it with dynamic offset symbols and 
>> still see some benefit, but in this case we really ought to be able to get 
>> all the way to C-level performance.
>> 
>> The name hasn't been formalized; this will all go through swift-evolution at 
>> some point. We thought about "fixed-layout" in the past, but that doesn't 
>> have the right connotations for something like Pair:
>> 
>> @fixedContents
>> public struct Pair {
>>   public var first: A
>>   public var second: A
>>   public init(first: A, second: A) { … }
>> }
>> 
>> This has known properties, but the layout depends on the generic argument, 
>> and if the generic argument is itself a type with unknown size then the 
>> actual layout won't be known until runtime.
>> 
>> Jordan
>> 
>> 
>>> On Sep 6, 2017, at 10:40, David Zarzycki >> > wrote:
>>> 
>>> Ah, now that I see the CGPoint example, I understand. Thanks! Ya, the 
>>> “hard” user-experience model I brought up feels wrong for CGPoint, etc. 
>>> (For non-Apple people, CGPoint is a struct of two doubles on 64-bit 
>>> machines add two floats on 32-bit machines.)
>>> 
>>> It wasn’t obvious to me from context that @fixedContents wasn’t / isn’t for 
>>> people trying to design a comprehensive ABI (disk, wire, etc), but just the 
>>> machine specific in memory ABI. I wish the name was better, but nothing 
>>> better seems obvious. (“@inMemoryABI”?)
>>> 
>>> Dave
>>> 
 On Sep 6, 2017, at 13:11, Jordan Rose >>> > wrote:
 
 I'd be okay with allowing the ABI attributes to control ordering, but I 
 would definitely not require them on every fixed-contents struct. We hope 
 making a struct fixed-contents isn't something people have to do too 
 often, but we don't want to drop them all the way into "hard" land when 
 they do it. That is, "CGPoint" can't already be "hard mode".
 
 Jordan
 
 
> On Sep 6, 2017, at 05:13, David Zarzycki  > wrote:
> 
> Hi Jordan,
> 
> I really doubt that “belt and suspenders” ABI attributes would drive 
> people to C, but reasonable people can certainly disagree on that.
> 
> Bertrand, when he was at Apple, used to say that “easy things should be 
> easy, and hard things should be possible”.
> 
> I think ABI related attributes fall into the latter category. In 
> particular, I think that trying to make ABI attributes too convenient 
> only does programmers a disservice in the long run because most 
> programmers aren't experts, and the cost of ignorance is huge when trying 
> to do ABI design.
> 
> With these thoughts in mind, I think that is reasonable for the language 
> to say: “If you want explicit control over a dimension of ABI decisions, 
> then you must deal with all of the associated complexity. Here is a 
> pointer to the documentation on dimension X that you were/are trying to 
> explicitly manage. If that is ’too hard’ for you, then you probably 
> shouldn’t be locking down this dimension of complexity yet.”
> 
> Dave
> 
>> On Sep 5, 2017, at 20:11, Jordan Rose > > wrote:
>> 
>> Hm. This is definitely an option, but I don't think it's really an 
>> acceptable user expe

Re: [swift-dev] What can you change in a fixed-contents struct?

[David Zarzycki via swift-dev]

I see. Would “@fixedSize” or “@abi(size)” be better names? In other words, the 
developer promises that whatever size the struct is now, it will be that way 
forever?

Also, wouldn’t the Pair example below require that ‘A’ also be 
@fixedContents? Otherwise what does @fixedContents mean if the elements aren’t 
fixed?

Dave


> On Sep 6, 2017, at 13:44, Jordan Rose  wrote:
> 
> I don't think that's the right way to think about it either. It's purely an 
> optimization tool to say "I won't add anything else to this struct", which 
> means the compiler can avoid indirection when manipulating the struct across 
> module boundaries. We could implement it with dynamic offset symbols and 
> still see some benefit, but in this case we really ought to be able to get 
> all the way to C-level performance.
> 
> The name hasn't been formalized; this will all go through swift-evolution at 
> some point. We thought about "fixed-layout" in the past, but that doesn't 
> have the right connotations for something like Pair:
> 
> @fixedContents
> public struct Pair {
>   public var first: A
>   public var second: A
>   public init(first: A, second: A) { … }
> }
> 
> This has known properties, but the layout depends on the generic argument, 
> and if the generic argument is itself a type with unknown size then the 
> actual layout won't be known until runtime.
> 
> Jordan
> 
> 
>> On Sep 6, 2017, at 10:40, David Zarzycki > > wrote:
>> 
>> Ah, now that I see the CGPoint example, I understand. Thanks! Ya, the “hard” 
>> user-experience model I brought up feels wrong for CGPoint, etc. (For 
>> non-Apple people, CGPoint is a struct of two doubles on 64-bit machines add 
>> two floats on 32-bit machines.)
>> 
>> It wasn’t obvious to me from context that @fixedContents wasn’t / isn’t for 
>> people trying to design a comprehensive ABI (disk, wire, etc), but just the 
>> machine specific in memory ABI. I wish the name was better, but nothing 
>> better seems obvious. (“@inMemoryABI”?)
>> 
>> Dave
>> 
>>> On Sep 6, 2017, at 13:11, Jordan Rose >> > wrote:
>>> 
>>> I'd be okay with allowing the ABI attributes to control ordering, but I 
>>> would definitely not require them on every fixed-contents struct. We hope 
>>> making a struct fixed-contents isn't something people have to do too often, 
>>> but we don't want to drop them all the way into "hard" land when they do 
>>> it. That is, "CGPoint" can't already be "hard mode".
>>> 
>>> Jordan
>>> 
>>> 
 On Sep 6, 2017, at 05:13, David Zarzycki >>> > wrote:
 
 Hi Jordan,
 
 I really doubt that “belt and suspenders” ABI attributes would drive 
 people to C, but reasonable people can certainly disagree on that.
 
 Bertrand, when he was at Apple, used to say that “easy things should be 
 easy, and hard things should be possible”.
 
 I think ABI related attributes fall into the latter category. In 
 particular, I think that trying to make ABI attributes too convenient only 
 does programmers a disservice in the long run because most programmers 
 aren't experts, and the cost of ignorance is huge when trying to do ABI 
 design.
 
 With these thoughts in mind, I think that is reasonable for the language 
 to say: “If you want explicit control over a dimension of ABI decisions, 
 then you must deal with all of the associated complexity. Here is a 
 pointer to the documentation on dimension X that you were/are trying to 
 explicitly manage. If that is ’too hard’ for you, then you probably 
 shouldn’t be locking down this dimension of complexity yet.”
 
 Dave
 
> On Sep 5, 2017, at 20:11, Jordan Rose  > wrote:
> 
> Hm. This is definitely an option, but I don't think it's really an 
> acceptable user experience. This feels like it'll drive people all the 
> way to declaring their types in C because Swift makes it too hard.
> 
> We do expect to have a tool to diff old and new modules at some point, 
> but we could do something even simpler here: make a public symbol with 
> the struct's layout in its name. That way, even 'nm' can tell if the 
> symbol disappears. (Of course, public symbols do have a small cost, since 
> this might not actually be the best idea.)
> 
> Another idea would be to restrict @fixedContents to require that all 
> stored properties appear contiguously in the struct, possibly even pinned 
> to the top or bottom, to indicate that order's not completely arbitrary. 
> Again, that's just an improvement, not full protection.
> 
> Jordan
> 
> 
>> On Sep 5, 2017, at 13:00, David Zarzycki > > wrote:
>> 
>> Hi Jordan,
>> 
>> Thanks for thinking about this. For whatever it may be worth, I’m 
>> concerned about 1) the ability to reorder 

Re: [swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

I don't think that's the right way to think about it either. It's purely an 
optimization tool to say "I won't add anything else to this struct", which 
means the compiler can avoid indirection when manipulating the struct across 
module boundaries. We could implement it with dynamic offset symbols and still 
see some benefit, but in this case we really ought to be able to get all the 
way to C-level performance.

The name hasn't been formalized; this will all go through swift-evolution at 
some point. We thought about "fixed-layout" in the past, but that doesn't have 
the right connotations for something like Pair:

@fixedContents
public struct Pair {
  public var first: A
  public var second: A
  public init(first: A, second: A) { … }
}

This has known properties, but the layout depends on the generic argument, and 
if the generic argument is itself a type with unknown size then the actual 
layout won't be known until runtime.

Jordan


> On Sep 6, 2017, at 10:40, David Zarzycki  wrote:
> 
> Ah, now that I see the CGPoint example, I understand. Thanks! Ya, the “hard” 
> user-experience model I brought up feels wrong for CGPoint, etc. (For 
> non-Apple people, CGPoint is a struct of two doubles on 64-bit machines add 
> two floats on 32-bit machines.)
> 
> It wasn’t obvious to me from context that @fixedContents wasn’t / isn’t for 
> people trying to design a comprehensive ABI (disk, wire, etc), but just the 
> machine specific in memory ABI. I wish the name was better, but nothing 
> better seems obvious. (“@inMemoryABI”?)
> 
> Dave
> 
>> On Sep 6, 2017, at 13:11, Jordan Rose > > wrote:
>> 
>> I'd be okay with allowing the ABI attributes to control ordering, but I 
>> would definitely not require them on every fixed-contents struct. We hope 
>> making a struct fixed-contents isn't something people have to do too often, 
>> but we don't want to drop them all the way into "hard" land when they do it. 
>> That is, "CGPoint" can't already be "hard mode".
>> 
>> Jordan
>> 
>> 
>>> On Sep 6, 2017, at 05:13, David Zarzycki >> > wrote:
>>> 
>>> Hi Jordan,
>>> 
>>> I really doubt that “belt and suspenders” ABI attributes would drive people 
>>> to C, but reasonable people can certainly disagree on that.
>>> 
>>> Bertrand, when he was at Apple, used to say that “easy things should be 
>>> easy, and hard things should be possible”.
>>> 
>>> I think ABI related attributes fall into the latter category. In 
>>> particular, I think that trying to make ABI attributes too convenient only 
>>> does programmers a disservice in the long run because most programmers 
>>> aren't experts, and the cost of ignorance is huge when trying to do ABI 
>>> design.
>>> 
>>> With these thoughts in mind, I think that is reasonable for the language to 
>>> say: “If you want explicit control over a dimension of ABI decisions, then 
>>> you must deal with all of the associated complexity. Here is a pointer to 
>>> the documentation on dimension X that you were/are trying to explicitly 
>>> manage. If that is ’too hard’ for you, then you probably shouldn’t be 
>>> locking down this dimension of complexity yet.”
>>> 
>>> Dave
>>> 
 On Sep 5, 2017, at 20:11, Jordan Rose >>> > wrote:
 
 Hm. This is definitely an option, but I don't think it's really an 
 acceptable user experience. This feels like it'll drive people all the way 
 to declaring their types in C because Swift makes it too hard.
 
 We do expect to have a tool to diff old and new modules at some point, but 
 we could do something even simpler here: make a public symbol with the 
 struct's layout in its name. That way, even 'nm' can tell if the symbol 
 disappears. (Of course, public symbols do have a small cost, since this 
 might not actually be the best idea.)
 
 Another idea would be to restrict @fixedContents to require that all 
 stored properties appear contiguously in the struct, possibly even pinned 
 to the top or bottom, to indicate that order's not completely arbitrary. 
 Again, that's just an improvement, not full protection.
 
 Jordan
 
 
> On Sep 5, 2017, at 13:00, David Zarzycki  > wrote:
> 
> Hi Jordan,
> 
> Thanks for thinking about this. For whatever it may be worth, I’m 
> concerned about 1) the ability to reorder declarations and 2) the 
> “either/or” nature of this proposal.
> 
> First, reordering: The ability to reorder declarations is deeply 
> ingrained into the subconsciousness of Swift programmers and for good 
> reasons. I think adding localized declaration order sensitivity is likely 
> to be very brittle and regrettable in the long run. I also think this 
> problem is made worse by having a type declaration context attribute 
> because it can easily get lost in the noise of nontrivial declarations. 
>>

Re: [swift-dev] What can you change in a fixed-contents struct?

[David Zarzycki via swift-dev]

Ah, now that I see the CGPoint example, I understand. Thanks! Ya, the “hard” 
user-experience model I brought up feels wrong for CGPoint, etc. (For non-Apple 
people, CGPoint is a struct of two doubles on 64-bit machines add two floats on 
32-bit machines.)

It wasn’t obvious to me from context that @fixedContents wasn’t / isn’t for 
people trying to design a comprehensive ABI (disk, wire, etc), but just the 
machine specific in memory ABI. I wish the name was better, but nothing better 
seems obvious. (“@inMemoryABI”?)

Dave

> On Sep 6, 2017, at 13:11, Jordan Rose  wrote:
> 
> I'd be okay with allowing the ABI attributes to control ordering, but I would 
> definitely not require them on every fixed-contents struct. We hope making a 
> struct fixed-contents isn't something people have to do too often, but we 
> don't want to drop them all the way into "hard" land when they do it. That 
> is, "CGPoint" can't already be "hard mode".
> 
> Jordan
> 
> 
>> On Sep 6, 2017, at 05:13, David Zarzycki > > wrote:
>> 
>> Hi Jordan,
>> 
>> I really doubt that “belt and suspenders” ABI attributes would drive people 
>> to C, but reasonable people can certainly disagree on that.
>> 
>> Bertrand, when he was at Apple, used to say that “easy things should be 
>> easy, and hard things should be possible”.
>> 
>> I think ABI related attributes fall into the latter category. In particular, 
>> I think that trying to make ABI attributes too convenient only does 
>> programmers a disservice in the long run because most programmers aren't 
>> experts, and the cost of ignorance is huge when trying to do ABI design.
>> 
>> With these thoughts in mind, I think that is reasonable for the language to 
>> say: “If you want explicit control over a dimension of ABI decisions, then 
>> you must deal with all of the associated complexity. Here is a pointer to 
>> the documentation on dimension X that you were/are trying to explicitly 
>> manage. If that is ’too hard’ for you, then you probably shouldn’t be 
>> locking down this dimension of complexity yet.”
>> 
>> Dave
>> 
>>> On Sep 5, 2017, at 20:11, Jordan Rose >> > wrote:
>>> 
>>> Hm. This is definitely an option, but I don't think it's really an 
>>> acceptable user experience. This feels like it'll drive people all the way 
>>> to declaring their types in C because Swift makes it too hard.
>>> 
>>> We do expect to have a tool to diff old and new modules at some point, but 
>>> we could do something even simpler here: make a public symbol with the 
>>> struct's layout in its name. That way, even 'nm' can tell if the symbol 
>>> disappears. (Of course, public symbols do have a small cost, since this 
>>> might not actually be the best idea.)
>>> 
>>> Another idea would be to restrict @fixedContents to require that all stored 
>>> properties appear contiguously in the struct, possibly even pinned to the 
>>> top or bottom, to indicate that order's not completely arbitrary. Again, 
>>> that's just an improvement, not full protection.
>>> 
>>> Jordan
>>> 
>>> 
 On Sep 5, 2017, at 13:00, David Zarzycki >>> > wrote:
 
 Hi Jordan,
 
 Thanks for thinking about this. For whatever it may be worth, I’m 
 concerned about 1) the ability to reorder declarations and 2) the 
 “either/or” nature of this proposal.
 
 First, reordering: The ability to reorder declarations is deeply ingrained 
 into the subconsciousness of Swift programmers and for good reasons. I 
 think adding localized declaration order sensitivity is likely to be very 
 brittle and regrettable in the long run. I also think this problem is made 
 worse by having a type declaration context attribute because it can easily 
 get lost in the noise of nontrivial declarations. The net result is that 
 people will frequently forget about local order sensitivity. Yes, the 
 compiler can engage in heroics and compare the previous module ABI and the 
 new module ABI for conflicts, but that seems risky, complex, slow, and 
 differently error prone.
 
 Second, the “either/or” nature of this proposal: What do you think about a 
 lightweight “belt and suspenders” solution whereby @fixedContents requires 
 that stored properties be lightly annotated with their layout order? For 
 example:
 
 @fixedContents(3) struct Foo {
   @abi(0) var x: Int
   func a() {
 // a thousand lines of ABI layout distraction
   }
   @abi(1) var y: Double
   func b() {
 // another thousand lines of ABI layout distraction
   }
   @abi(2) var z: String
 }
 
 That would enable both renaming and reordering, would it not? This 
 approach would also aid the compiler in quickly detecting hastily 
 added/deleted declarations too because the count of @abi([0-9]+) 
 declarations wouldn’t match the number passed to @fixedContents.

Re: [swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

I'd be okay with allowing the ABI attributes to control ordering, but I would 
definitely not require them on every fixed-contents struct. We hope making a 
struct fixed-contents isn't something people have to do too often, but we don't 
want to drop them all the way into "hard" land when they do it. That is, 
"CGPoint" can't already be "hard mode".

Jordan


> On Sep 6, 2017, at 05:13, David Zarzycki  wrote:
> 
> Hi Jordan,
> 
> I really doubt that “belt and suspenders” ABI attributes would drive people 
> to C, but reasonable people can certainly disagree on that.
> 
> Bertrand, when he was at Apple, used to say that “easy things should be easy, 
> and hard things should be possible”.
> 
> I think ABI related attributes fall into the latter category. In particular, 
> I think that trying to make ABI attributes too convenient only does 
> programmers a disservice in the long run because most programmers aren't 
> experts, and the cost of ignorance is huge when trying to do ABI design.
> 
> With these thoughts in mind, I think that is reasonable for the language to 
> say: “If you want explicit control over a dimension of ABI decisions, then 
> you must deal with all of the associated complexity. Here is a pointer to the 
> documentation on dimension X that you were/are trying to explicitly manage. 
> If that is ’too hard’ for you, then you probably shouldn’t be locking down 
> this dimension of complexity yet.”
> 
> Dave
> 
>> On Sep 5, 2017, at 20:11, Jordan Rose > > wrote:
>> 
>> Hm. This is definitely an option, but I don't think it's really an 
>> acceptable user experience. This feels like it'll drive people all the way 
>> to declaring their types in C because Swift makes it too hard.
>> 
>> We do expect to have a tool to diff old and new modules at some point, but 
>> we could do something even simpler here: make a public symbol with the 
>> struct's layout in its name. That way, even 'nm' can tell if the symbol 
>> disappears. (Of course, public symbols do have a small cost, since this 
>> might not actually be the best idea.)
>> 
>> Another idea would be to restrict @fixedContents to require that all stored 
>> properties appear contiguously in the struct, possibly even pinned to the 
>> top or bottom, to indicate that order's not completely arbitrary. Again, 
>> that's just an improvement, not full protection.
>> 
>> Jordan
>> 
>> 
>>> On Sep 5, 2017, at 13:00, David Zarzycki >> > wrote:
>>> 
>>> Hi Jordan,
>>> 
>>> Thanks for thinking about this. For whatever it may be worth, I’m concerned 
>>> about 1) the ability to reorder declarations and 2) the “either/or” nature 
>>> of this proposal.
>>> 
>>> First, reordering: The ability to reorder declarations is deeply ingrained 
>>> into the subconsciousness of Swift programmers and for good reasons. I 
>>> think adding localized declaration order sensitivity is likely to be very 
>>> brittle and regrettable in the long run. I also think this problem is made 
>>> worse by having a type declaration context attribute because it can easily 
>>> get lost in the noise of nontrivial declarations. The net result is that 
>>> people will frequently forget about local order sensitivity. Yes, the 
>>> compiler can engage in heroics and compare the previous module ABI and the 
>>> new module ABI for conflicts, but that seems risky, complex, slow, and 
>>> differently error prone.
>>> 
>>> Second, the “either/or” nature of this proposal: What do you think about a 
>>> lightweight “belt and suspenders” solution whereby @fixedContents requires 
>>> that stored properties be lightly annotated with their layout order? For 
>>> example:
>>> 
>>> @fixedContents(3) struct Foo {
>>>   @abi(0) var x: Int
>>>   func a() {
>>> // a thousand lines of ABI layout distraction
>>>   }
>>>   @abi(1) var y: Double
>>>   func b() {
>>> // another thousand lines of ABI layout distraction
>>>   }
>>>   @abi(2) var z: String
>>> }
>>> 
>>> That would enable both renaming and reordering, would it not? This approach 
>>> would also aid the compiler in quickly detecting hastily added/deleted 
>>> declarations too because the count of @abi([0-9]+) declarations wouldn’t 
>>> match the number passed to @fixedContents.
>>> 
>>> Dave
>>> 
>>> 
>>> 
 On Sep 5, 2017, at 14:59, Jordan Rose via swift-dev >>> > wrote:
 
 Hey, all. In preparation for the several proposals we have to come this 
 year, I cleaned up docs/LibraryEvolution.rst 
  a little bit based on what's 
 changed in Swift 4. This is mostly just mentioning things about generic 
 subscripts, but there is one issue that I remember John bringing up some 
 time in this past year: once you've made a struct fixed-contents, what can 
 you change about its stored properties?
 
> To opt out of this flexibility, a struct may be marked '@fixedContents'. 
> Thi

Re: [swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

> On Sep 5, 2017, at 18:37, Nevin Brackett-Rozinsky via swift-dev 
>  wrote:
> 
> On Tue, Sep 5, 2017 at 6:08 PM, Slava Pestov via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> We expect that “define your struct in C” is still the way to go for layout 
> compatibility with other languages and systems.
> 
> Are there plans (however tentative) to eventually make it possible to specify 
> the exact memory layout of a struct in Swift?
> 
> It seems like something we will have to tackle in order for Swift to become a 
> serious systems-level programming language.

There's nothing inherently wrong with having a 'packedLayout' attribute or 
similar (as long as the compiler can enforce alignment requirements for 
non-trivial types), but neither is it urgent since you can do the same thing in 
C. It's a feature that can be added at any time, just not to existing 
fixed-contents structs.

Jordan

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

Re: [swift-dev] how much of non-Swift in Swif

[Alex Blewitt via swift-dev]

> On 6 Sep 2017, at 11:29, blaster_in_black via swift-dev  
> wrote:
> 
> Hi, Alex, and thank you so much for such a throroughly reply!
> 
> Abusing your good will, let me ask you yet another question. I understand, as 
> you've pointed out, that certain parts of functionality shall always be 
> implemented in low-level language with direct access to syscalls, such as 
> C/C++. Are you able to suggest me a way to find all, or at least most of 
> those parts? I'd like to estimate what they represent - what they build and 
> provide on top of syscalls and libc.

Well, one way would be to clone the https://github.com/apple/swift/ 
 repository and then find out any files which 
end in .c or .cpp :)

The problem is that there's a lot of stuff there, which means it's difficult to 
answer your question directly. In addition, Swift builds upon other libraries - 
for example, using ICU to perform the Unicode boundaries - and it's not clear 
where you want to draw the line.

Most of the Swift infrastructure is built upon LLVM - in fact, the Swift REPL 
is really just an extra set of runtime functions on top of the existing 
LLVM/LLDB type repls (you can switch into LLDB using : in a Swift interpreter, 
and back to Swift with repl). LLDB in turn has Python embedded within which you 
can run with 'script':

$ swift
Welcome to Apple Swift version 4.0-dev (LLVM f53eb03c15, Clang 1757394ff0, 
Swift 75b7e05e20). Type :help for assistance.
  1> :
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> print("Hello from Python in LLDB in Swift")
Hello from Python in LLDB in Swift
>>> 

I'm not sure what kind of 'syscalls' and 'libc' you are looking for, but you 
can use various tracing programs (e.g. strace, dtrace) to find out where they 
are being called directly, or you could run it under lldb and set various 
breakpoints to do the same.

Finally, the resulting executable generated by a Swift compiler consists of a 
number of parts; information generated by the compiler and optimiser phases, 
calls out to external libraries (like libc or libicu), as well as calls to 
runtime functionality used by the Swift runtime, such as memory allocation and 
reference counting. There isn't a clear delineation of where those come from, 
so unless you want to get a little bit more specific about what you're hoping 
to find, you're probably best just spelunking through the codebase.

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

Re: [swift-dev] What can you change in a fixed-contents struct?

[David Zarzycki via swift-dev]

Hi Jordan,

I really doubt that “belt and suspenders” ABI attributes would drive people to 
C, but reasonable people can certainly disagree on that.

Bertrand, when he was at Apple, used to say that “easy things should be easy, 
and hard things should be possible”.

I think ABI related attributes fall into the latter category. In particular, I 
think that trying to make ABI attributes too convenient only does programmers a 
disservice in the long run because most programmers aren't experts, and the 
cost of ignorance is huge when trying to do ABI design.

With these thoughts in mind, I think that is reasonable for the language to 
say: “If you want explicit control over a dimension of ABI decisions, then you 
must deal with all of the associated complexity. Here is a pointer to the 
documentation on dimension X that you were/are trying to explicitly manage. If 
that is ’too hard’ for you, then you probably shouldn’t be locking down this 
dimension of complexity yet.”

Dave

> On Sep 5, 2017, at 20:11, Jordan Rose  wrote:
> 
> Hm. This is definitely an option, but I don't think it's really an acceptable 
> user experience. This feels like it'll drive people all the way to declaring 
> their types in C because Swift makes it too hard.
> 
> We do expect to have a tool to diff old and new modules at some point, but we 
> could do something even simpler here: make a public symbol with the struct's 
> layout in its name. That way, even 'nm' can tell if the symbol disappears. 
> (Of course, public symbols do have a small cost, since this might not 
> actually be the best idea.)
> 
> Another idea would be to restrict @fixedContents to require that all stored 
> properties appear contiguously in the struct, possibly even pinned to the top 
> or bottom, to indicate that order's not completely arbitrary. Again, that's 
> just an improvement, not full protection.
> 
> Jordan
> 
> 
>> On Sep 5, 2017, at 13:00, David Zarzycki > > wrote:
>> 
>> Hi Jordan,
>> 
>> Thanks for thinking about this. For whatever it may be worth, I’m concerned 
>> about 1) the ability to reorder declarations and 2) the “either/or” nature 
>> of this proposal.
>> 
>> First, reordering: The ability to reorder declarations is deeply ingrained 
>> into the subconsciousness of Swift programmers and for good reasons. I think 
>> adding localized declaration order sensitivity is likely to be very brittle 
>> and regrettable in the long run. I also think this problem is made worse by 
>> having a type declaration context attribute because it can easily get lost 
>> in the noise of nontrivial declarations. The net result is that people will 
>> frequently forget about local order sensitivity. Yes, the compiler can 
>> engage in heroics and compare the previous module ABI and the new module ABI 
>> for conflicts, but that seems risky, complex, slow, and differently error 
>> prone.
>> 
>> Second, the “either/or” nature of this proposal: What do you think about a 
>> lightweight “belt and suspenders” solution whereby @fixedContents requires 
>> that stored properties be lightly annotated with their layout order? For 
>> example:
>> 
>> @fixedContents(3) struct Foo {
>>   @abi(0) var x: Int
>>   func a() {
>> // a thousand lines of ABI layout distraction
>>   }
>>   @abi(1) var y: Double
>>   func b() {
>> // another thousand lines of ABI layout distraction
>>   }
>>   @abi(2) var z: String
>> }
>> 
>> That would enable both renaming and reordering, would it not? This approach 
>> would also aid the compiler in quickly detecting hastily added/deleted 
>> declarations too because the count of @abi([0-9]+) declarations wouldn’t 
>> match the number passed to @fixedContents.
>> 
>> Dave
>> 
>> 
>> 
>>> On Sep 5, 2017, at 14:59, Jordan Rose via swift-dev >> > wrote:
>>> 
>>> Hey, all. In preparation for the several proposals we have to come this 
>>> year, I cleaned up docs/LibraryEvolution.rst 
>>>  a little bit based on what's 
>>> changed in Swift 4. This is mostly just mentioning things about generic 
>>> subscripts, but there is one issue that I remember John bringing up some 
>>> time in this past year: once you've made a struct fixed-contents, what can 
>>> you change about its stored properties?
>>> 
 To opt out of this flexibility, a struct may be marked '@fixedContents'. 
 This promises that no stored properties will be added to or removed from 
 the struct, even non-public ones.
>>> 
>>> Interestingly, this means that you can have non-public members of a 
>>> fixed-contents struct. This is actually pretty sensible: it's the 
>>> equivalent of a C++ class with non-public fields but a defaulted, inlinable 
>>> copy constructor. Any inlinable members can access these properties 
>>> directly as well; it's just outsiders that can't see them. But if inlinable 
>>> code can reference these things, and if we really want them to be fast, 
>

Re: [swift-dev] how much of non-Swift in Swif

[blaster_in_black via swift-dev]

Hi, Alex, and thank you so much for such a throroughly reply!

> The "Builtin" comes from a number of different places, e.g.:
>
> https://github.com/apple/swift/blob/master/include/swift/AST/Builtins.def
> https://github.com/apple/swift/blob/master/lib/AST/Builtins.cpp
>
> They aren't directly implemented in LLVM IR as such, but rather the parser 
> replaces uses of Builtin.Word with the appropriate type via 
> SILType::getBuiltinWordType and BuiltinIntegerType::getWordType.
>
> Normally these aren't accessible to Swift programs, but if you compile with 
> -parse-stdlib you can see what effect it has on the generated output. Looking 
> at the -emit-sil is an interesting way of seeing what is produced. (You can 
> also use a GUI tool I wrote called SILInspector, which runs the commands and 
> hosts them in a text field for ease of use.)

It looks I was mistaken then. Thanks for the clarification.

> The SwiftShims are a set of additional functions that allow C functions to be 
> exposed as platform-independent Swift functions:
>
> https://github.com/apple/swift/tree/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims
>
> https://github.com/apple/swift/blob/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims/LibcShims.h

I get it. Again, I was getting only part of the picture here. I thought 
LibcShims was not intended for that purpose but just "happened" to be 
implemented in C more than not.

>> 2) Are you aware of any project out there that aims to minimize, or at least 
>> make more consistent (...)
>
> I'm not sure what question you are asking here. If you are asking "Is there a 
> desire or goal to move away from C based functions into Swift functions" then 
> the answer is likely to be no; some of the functions need to be implemented 
> in C because they are platform specific or use e.g. C++ like namespaces, and 
> the bulk of the compiler and intrinsics are written in C++ already.
>
> Alex

I was partially mistaken. Before your clarifications above, I was wrongly 
perceiving what seemed like a lot of "embedded C code" here and there, and so I 
was wondering whether in the future that would be somehow taken together into a 
one central C/C++ external library or runtime (e.g. into a BuiltIn-like class 
or some other). But I see now there is no such lack of consistency, so my 
question is not valid anymore.

Abusing your good will, let me ask you yet another question. I understand, as 
you've pointed out, that certain parts of functionality shall always be 
implemented in low-level language with direct access to syscalls, such as 
C/C++. Are you able to suggest me a way to find all, or at least most of those 
parts? I'd like to estimate what they represent - what they build and provide 
on top of syscalls and libc.

Thanks again!

David___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] how much of non-Swift in Swif

[Alex Blewitt via swift-dev]

> On 6 Sep 2017, at 10:26, blaster_in_black via swift-dev  
> wrote:
> 
> 1) How much and what types of interfaces with non-Swift code is there in the 
> standard library and the runtime? I have seen references to the "Builtin" 
> class, that as I understand is directly implemented in LLVM IR language, and 
> also calls to C++ functions ("SwiftShims" is full of that). Is there any more 
> "boundary" with non-Swift parts of the implementation?

The "Builtin" comes from a number of different places, e.g.:

https://github.com/apple/swift/blob/master/include/swift/AST/Builtins.def 

https://github.com/apple/swift/blob/master/lib/AST/Builtins.cpp 
 

They aren't directly implemented in LLVM IR as such, but rather the parser 
replaces uses of Builtin.Word with the appropriate type via 
SILType::getBuiltinWordType and BuiltinIntegerType::getWordType.

Normally these aren't accessible to Swift programs, but if you compile with 
-parse-stdlib you can see what effect it has on the generated output. Looking 
at the -emit-sil is an interesting way of seeing what is produced. (You can 
also use a GUI tool I wrote called SILInspector, which runs the commands and 
hosts them in a text field for ease of use.)

The SwiftShims are a set of additional functions that allow C functions to be 
exposed as platform-independent Swift functions:

https://github.com/apple/swift/tree/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims
 


https://github.com/apple/swift/blob/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims/LibcShims.h
 

 

> 2) Are you aware of any project out there that aims to minimize, or at least 
> make more consistent, the amount of references to non-Swift functions and 
> types in the standard library? I know about Pure Swift's "SwiftFoundation" 
> and other artifacts of them, but as far as I know they do not dig into the 
> standard library.

I'm not sure what question you are asking here. If you are asking "Is there a 
desire or goal to move away from C based functions into Swift functions" then 
the answer is likely to be no; some of the functions need to be implemented in 
C because they are platform specific or use e.g. C++ like namespaces, and the 
bulk of the compiler and intrinsics are written in C++ already.

Foundation, on the other hand, has a number of C functions that have been 
inherited from the Darwin codebase, which has a collection of C underlying 
concepts and then higher level wrappers. While it would be technically possible 
to rewrite working code with other working code, the focus has been on filling 
out the gaps in places where there isn't working code at the moment. In 
addition, it's generally unproductive to rewrite working and tested code with 
new code unless there's a specific reason (speed, portability, security) to do 
so.

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

[swift-dev] how much of non-Swift in Swif

[blaster_in_black via swift-dev]

Hi Swift developers,

nice to meet you all in this list.
While having a look at Swift's source code, I am not able to really answer 
myself two questions:

1) How much and what types of interfaces with non-Swift code is there in the 
standard library and the runtime? I have seen references to the "Builtin" 
class, that as I understand is directly implemented in LLVM IR language, and 
also calls to C++ functions ("SwiftShims" is full of that). Is there any more 
"boundary" with non-Swift parts of the implementation?
2) Are you aware of any project out there that aims to minimize, or at least 
make more consistent, the amount of references to non-Swift functions and types 
in the standard library? I know about Pure Swift's "SwiftFoundation" and other 
artifacts of them, but as far as I know they do not dig into the standard 
library.

Thanking you in advance for the answers!

Cheers,

David___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Swift build on ppc64le platform

[Meghali Dhoble via swift-dev]

Thanks John, for the response.
We have a patch added already for ppc64 support at llvm, however still the
failures seen,
I will try to opt for 2nd  option and see if that helps.

 Thanks,
Meghali



From:   John McCall 
To: Meghali Dhoble 
Cc: swift-dev , Graydon Hoare

Date:   08/28/2017 09:59 PM
Subject:Re: [swift-dev] Swift build on ppc64le platform
Sent by:rjmcc...@apple.com



  On Aug 28, 2017, at 9:08 AM, Meghali Dhoble via swift-dev <
  swift-dev@swift.org> wrote:


  Hi,
  I have been working towards getting the swift source code built on my
  power (ppc64le) platform on Ubuntu16.04 OS.
  I am observing build issues and looking for some help here. Please
  redirect me if this is not the right place for these questions.

  I would like to understand the pre-requisites and the hardware
  configurations required to build this language.
  The error I am getting look like memory issues as the process is
  being killed abruptly. I am attaching the log herewith for reference.


I don't see anything like that in the log.  It looks like an ordinary
compiler error relating to our custom calling convention.

You need to either
1. implement swiftcc in LLVM's ppc64 backend and then teach Clang that it's
legal there or
2. configure Swift to not try to use it.

In the short term, I suspect that (2) is the right approach.  Graydon was
at least thinking about doing some work recently that would be aimed at
making it easier to do this kind of configuration; CC'ing him explicitly to
see if there's been progress there.

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