[swift-dev] Linker script on Linux

[Luke Howard via swift-dev]

Per [SR-404], anything that consumed libFoundation could not dynamically cast 
to a Foundation protocol because the build script was missing the magic 
swift.ld linker script to advertise the start of the protocol conformances 
table. (There’s also some weird issue where dlsym() seems to return the 
previous table if it can’t find one, but that’s a separate issue.)

The build system is opaque enough that I’m not exactly sure how the linker is 
driven when building shared libraries, but it would be great if the linker 
script was added automagically.

— Luke
--
www.lukehoward.com
soundcloud.com/lukehoward

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Joe Groff via swift-dev]

> On Dec 29, 2015, at 9:04 PM, Luke Howard via swift-dev  
> wrote:
> 
> I’m seeing an assertion failure when I try to compile the following on Linux:
> 
>   typealias TypeMetadataAccessor = @convention(c) () -> AnyClass?
> 
> The assertion failing is:
> 
>assert(getASTContext().LangOpts.EnableObjCInterop ||
>   *repr != MetatypeRepresentation::ObjC);
> 
> in ExistentialMetatypeType::ExistentialMetatypeType(). Commenting it out and 
> the code compiles and works.
> 
> Can someone that understands the compiler suggest the correct fix?

It looks like you're trying to poke at private runtime metadata structures; 
please don't do that. What are you trying to do?

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Philippe Hausler via swift-dev]

That is the asset in the compiler that is being hit when the code 
unsafeBitCasts to a c function.

typealias TypeMetadataAccessor = @convention(c) () -> AnyClass?
let accessor = unsafeBitCast(symbol, TypeMetadataAccessor.self) // <— this 
causes the compiler to assert there.

> On Dec 30, 2015, at 10:03 AM, Joe Groff via swift-dev  
> wrote:
> 
> 
>> On Dec 29, 2015, at 9:04 PM, Luke Howard via swift-dev  
>> wrote:
>> 
>> I’m seeing an assertion failure when I try to compile the following on Linux:
>> 
>>  typealias TypeMetadataAccessor = @convention(c) () -> AnyClass?
>> 
>> The assertion failing is:
>> 
>>   assert(getASTContext().LangOpts.EnableObjCInterop ||
>>  *repr != MetatypeRepresentation::ObjC);
>> 
>> in ExistentialMetatypeType::ExistentialMetatypeType(). Commenting it out and 
>> the code compiles and works.
>> 
>> Can someone that understands the compiler suggest the correct fix?
> 
> It looks like you're trying to poke at private runtime metadata structures; 
> please don't do that. What are you trying to do?
> 
> -Joe
> ___
> 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] ExistentialMetatypeType assertion failure on Linux

[Joe Groff via swift-dev]

> On Dec 30, 2015, at 10:05 AM, Philippe Hausler  wrote:
> 
> That is the asset in the compiler that is being hit when the code 
> unsafeBitCasts to a c function.
> 
> typealias TypeMetadataAccessor = @convention(c) () -> AnyClass?
> let accessor = unsafeBitCast(symbol, TypeMetadataAccessor.self) // <— this 
> causes the compiler to assert there.

Under the ObjC runtime model, C and ObjC APIs represent class metatypes as 
pointers to their ObjC class representation, but that distinction doesn't 
matter in non-ObjC interop. This is easy to fix, but I'll reiterate that type 
metadata accessors are something you almost certainly have no business directly 
interacting with. What are you trying to do?

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

[swift-dev] Should we remove _customContainsEquatableElement from stdlib?

[Ling Wang via swift-dev]

After reviewing the code of stdlib I found no one actually implements 
_customContainsEquatableElement:
1. Its default implementation in `SequenceType` just returns nil.
2. The implementation in `Set` delegates to `contains` which is bad because it 
reverses their relationship: the default implementation of `contains` in 
`SequenceType` delegates to `_customContainsEquatableElement`.
3. In all other place it just delegates to another `SequenceType`.

So no one is doing real work.

If the current _customContainsEquatableElement is only a relic I suggest we 
remove it and clean up related code.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Luke Howard via swift-dev]

> On 31 Dec 2015, at 5:03 AM, Joe Groff  wrote:
> 
>> 
>> On Dec 29, 2015, at 9:04 PM, Luke Howard via swift-dev  
>> wrote:
>> 
>> I’m seeing an assertion failure when I try to compile the following on Linux:
>> 
>>  typealias TypeMetadataAccessor = @convention(c) () -> AnyClass?
>> 
>> The assertion failing is:
>> 
>>   assert(getASTContext().LangOpts.EnableObjCInterop ||
>>  *repr != MetatypeRepresentation::ObjC);
>> 
>> in ExistentialMetatypeType::ExistentialMetatypeType(). Commenting it out and 
>> the code compiles and works.
>> 
>> Can someone that understands the compiler suggest the correct fix?
> 
> It looks like you're trying to poke at private runtime metadata structures; 
> please don't do that. What are you trying to do?

Per our exchange yesterday – implement NSStringFromClass() heuristics for 
NSKeyedArchiver

A better solution would be to provide a proposed API/patch to the runtime but I 
was just trying to get the NSCoding branch testable on Linux first – can’t 
tackle everything at once.

More:

https://bugs.swift.org/browse/SR-381

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Luke Howard via swift-dev]

>> It looks like you're trying to poke at private runtime metadata structures; 
>> please don't do that. What are you trying to do?
> 
> Per our exchange yesterday – implement NSStringFromClass() heuristics for 
> NSKeyedArchiver

Sorry I mean NSClassFromString(). I thought indirecting the lookup through the 
metadata accessor was at least a little bit less bad than accessing it 
directly. :)

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

Re: [swift-dev] Should we remove _customContainsEquatableElement from stdlib?

[Dmitri Gribenko via swift-dev]

On Wed, Dec 30, 2015 at 8:34 PM, Ling Wang via swift-dev
 wrote:
> After reviewing the code of stdlib I found no one actually implements 
> _customContainsEquatableElement:
> 1. Its default implementation in `SequenceType` just returns nil.
> 2. The implementation in `Set` delegates to `contains` which is bad because 
> it reverses their relationship: the default implementation of `contains` in 
> `SequenceType` delegates to `_customContainsEquatableElement`.
> 3. In all other place it just delegates to another `SequenceType`.
>
> So no one is doing real work.
>
> If the current _customContainsEquatableElement is only a relic I suggest we 
> remove it and clean up related code.

It is not a relic.  It allows the contains() method to perform dynamic
dispatch in case the container knows something extra about the
elements.

Consider the case when you have a Set typed as a plain Sequence or a
Collection.  In that case, you won't be able to call the custom
Set.contains() method, the overload resolution will only see the
protocol extension.  This extra entry point,
_customContainsEquatableElement, allows us to perform dynamic dispatch
and use the fast Set implementation if it is available.

Dmitri

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Joe Groff via swift-dev]

> On Dec 30, 2015, at 2:41 PM, Luke Howard  wrote:
> 
> 
>>> It looks like you're trying to poke at private runtime metadata structures; 
>>> please don't do that. What are you trying to do?
>> 
>> Per our exchange yesterday – implement NSStringFromClass() heuristics for 
>> NSKeyedArchiver
> 
> Sorry I mean NSClassFromString(). I thought indirecting the lookup through 
> the metadata accessor was at least a little bit less bad than accessing it 
> directly. :)

If you're experimenting privately that's OK, but I'd prefer to get the runtime 
functionality in place before committing anything. We already have our hands 
full trying to clean up and stabilize the standard library/runtime interfaces.

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Philippe Hausler via swift-dev]

> On Dec 30, 2015, at 3:21 PM, Joe Groff via swift-dev  
> wrote:
> 
> 
>> On Dec 30, 2015, at 2:41 PM, Luke Howard  wrote:
>> 
>> 
 It looks like you're trying to poke at private runtime metadata 
 structures; please don't do that. What are you trying to do?
>>> 
>>> Per our exchange yesterday – implement NSStringFromClass() heuristics for 
>>> NSKeyedArchiver
>> 
>> Sorry I mean NSClassFromString(). I thought indirecting the lookup through 
>> the metadata accessor was at least a little bit less bad than accessing it 
>> directly. :)
> 
> If you're experimenting privately that's OK, but I'd prefer to get the 
> runtime functionality in place before committing anything. We already have 
> our hands full trying to clean up and stabilize the standard library/runtime 
> interfaces.
> 
> -Joe
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev


Yep and that is why I am holding off on merging this just yet until we can get 
something up and rolling from the stdlib to support this.
For now we could just limit these to the list of hand coded class to string 
conversions and omit the NSStringFromClass/NSClassFromString transform; that 
way we give the stdlib a bit of time to get back on their feet from the break 
and get this code in.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] SIL: "unowned" the calling convention and "unowned" the variable ownership convention

[Emanuel Zephir via swift-dev]

Prior to this e-mail, it wasn't clear to me that there were two
different "unowned" concepts.

+1 in favor of the rename.

--Emanuel

On Tue, Dec 29, 2015 at 3:18 PM, Michael Gottesman via swift-dev
 wrote:
> One form of overloading that we currently have at the SIL level are the 
> notions of the "unowned" calling convention and "unowned" the variable 
> ownership convention.
>
> For those who are unfamiliar with the unowned calling convention consider the 
> following:
>
> @tmp : $@convention(thin) (@owned Array, Array, Int, Int) -> 
> Array
>
> In this case the first parameter is passed in @owned (i.e. +1) and the second 
> parameter is passed in as "unowned". Unowned is a form of +0 parameter 
> passing that essentially means that the callee needs to take ownership of the 
> value (ideally) before performing any side-effect having operations.
>
> Overloading the term "unowned" in this way is confusing for new people at the 
> SIL level. I would like to propose that we rename the unowned calling 
> convention to something else (since unowned the variable ownership convention 
> corresponds to a swift level concept that will be more difficult to change). 
> Additionally no matter what we do, we should annotate "unowned" parameters 
> and return values with an appropriate @"..." sigil to make it absolutely 
> clear visually what the convention is.
>
> In terms of names, I am partial to the name "immediate". My reasoning for 
> using the term immediate is related to SGFContext in SILGen. In SILGen, there 
> are three types of desired transfers defined by the DesiredTransfer enum.
>
>   enum DesiredTransfer {
> PlusOne,
> ImmediatePlusZero,
> GuaranteedPlusZero,
>   };
>
> PlusOne refers to @owned, GuaranteedPlusZero refers to @guaranteed, and if my 
> memory is correct, ImmediatePlusZero refers to unowned. It seems natural to 
> me to choose immediate for the name of the convention to match the 
> terminology in SGFContext.
>
> Comments, flames, etc?
>
> Michael
> ___
> 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] ExistentialMetatypeType assertion failure on Linux

[Luke Howard via swift-dev]

> On 31 Dec 2015, at 10:24 AM, Philippe Hausler  wrote:
> 
> Yep and that is why I am holding off on merging this just yet until we can 
> get something up and rolling from the stdlib to support this.
> For now we could just limit these to the list of hand coded class to string 
> conversions and omit the NSStringFromClass/NSClassFromString transform; that 
> way we give the stdlib a bit of time to get back on their feet from the break 
> and get this code in.

Your call; I know perfect is the enemy of good enough, but I’m definitely 
interested in helping get something in stdlib once we decide on what to do re: 
mangling etc.

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Philippe Hausler via swift-dev]

> On Dec 30, 2015, at 3:55 PM, Luke Howard  wrote:
> 
> 
>> On 31 Dec 2015, at 10:24 AM, Philippe Hausler  wrote:
>> 
>> Yep and that is why I am holding off on merging this just yet until we can 
>> get something up and rolling from the stdlib to support this.
>> For now we could just limit these to the list of hand coded class to string 
>> conversions and omit the NSStringFromClass/NSClassFromString transform; that 
>> way we give the stdlib a bit of time to get back on their feet from the 
>> break and get this code in.
> 
> Your call; I know perfect is the enemy of good enough, but I’m definitely 
> interested in helping get something in stdlib once we decide on what to do 
> re: mangling etc.
> 
> — Luke

I really want to merge in the rest of the coders; so lets go ahead and omit the 
mangling stuff and leave it just as the Foundation classes . That will be a 
huge win in my book, it gives us something that is testable and functional 
enough to do some pretty impressive demonstrations of archiving.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Luke Howard via swift-dev]

> I really want to merge in the rest of the coders; so lets go ahead and omit 
> the mangling stuff and leave it just as the Foundation classes . That will be 
> a huge win in my book, it gives us something that is testable and functional 
> enough to do some pretty impressive demonstrations of archiving.

OK, the version I’ve pushed now removes the code that was poking into runtime 
structures but still uses dlopen()/the metadata accessor for 
NSClassFromString(). Tests verify on OS X and Linux (with compiler fix).

If you want to change this further to use a static mapping table, go for it, 
but I’d rather focus my time on getting the appropriate API into stdlib.

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

Re: [swift-dev] Should we remove _customContainsEquatableElement from stdlib?

[Ling Wang via swift-dev]

Got it. `contains` is only declared in extension. Interesting workaround. 
Thanks.

> On Dec 30, 2015, at 4:45 PM, Dmitri Gribenko  wrote:
> 
> On Wed, Dec 30, 2015 at 8:34 PM, Ling Wang via swift-dev
>  wrote:
>> After reviewing the code of stdlib I found no one actually implements 
>> _customContainsEquatableElement:
>> 1. Its default implementation in `SequenceType` just returns nil.
>> 2. The implementation in `Set` delegates to `contains` which is bad because 
>> it reverses their relationship: the default implementation of `contains` in 
>> `SequenceType` delegates to `_customContainsEquatableElement`.
>> 3. In all other place it just delegates to another `SequenceType`.
>> 
>> So no one is doing real work.
>> 
>> If the current _customContainsEquatableElement is only a relic I suggest we 
>> remove it and clean up related code.
> 
> It is not a relic.  It allows the contains() method to perform dynamic
> dispatch in case the container knows something extra about the
> elements.
> 
> Consider the case when you have a Set typed as a plain Sequence or a
> Collection.  In that case, you won't be able to call the custom
> Set.contains() method, the overload resolution will only see the
> protocol extension.  This extra entry point,
> _customContainsEquatableElement, allows us to perform dynamic dispatch
> and use the fast Set implementation if it is available.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

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

Re: [swift-dev] Should we remove _customContainsEquatableElement from stdlib?

[Kevin Ballard via swift-dev]

FWIW, once we have conditional protocol conformance (`extension ... : Proto 
where ...`), and if we get rid of the circular protocol inheritance limitation 
(two protocols that inherit from each other, which should in theory be fine), 
then we can say something like

protocol EquatableSequenceType : SequenceType {
func contains(element: Self.Generator.Element) -> Bool
}

extension SequenceType : EquatableSequenceType where Self.Generator.Element : 
Equatable {
func contains(element: Self.Generator.Element) -> Bool {
// ...
}
}

This way the method can actually be overridden directly without requiring any 
hacks like _customContainsEquatableElement.

We could work around the circular protocol inheritance thing by declaring a 
`typealias _Element : Equatable` in EquatableSequenceType instead of having the 
inheritance, and then just set `typealias _Element = Self.Generator.Element` in 
the protocol extension on SequenceType, but that does in theory let 
implementing types actually change the type of the contains() method parameter 
by overriding the typealias, which is a bit weird. Alternatively, we could work 
around it by allowing you to say `extension Any : EquatableSequenceType where 
Self : SequenceType { ... }` and having that essentially extend every concrete 
type that conforms to SequenceType, which means SequenceType itself doesn't 
conform to EquatableSequenceType and therefore there's no circular protocol 
inheritance, but I'm not sure if this is actually an approach we want to take 
(although this is precisely what Rust does and it works for them).

-Kevin Ballard

On Wed, Dec 30, 2015, at 10:34 AM, Ling Wang via swift-dev wrote:
> After reviewing the code of stdlib I found no one actually implements 
> _customContainsEquatableElement:
> 1. Its default implementation in `SequenceType` just returns nil.
> 2. The implementation in `Set` delegates to `contains` which is bad because 
> it reverses their relationship: the default implementation of `contains` in 
> `SequenceType` delegates to `_customContainsEquatableElement`.
> 3. In all other place it just delegates to another `SequenceType`.
> 
> So no one is doing real work.
> 
> If the current _customContainsEquatableElement is only a relic I suggest we 
> remove it and clean up related code.
> ___
> 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

[swift-dev] Where are @_attributes documented?

[Ling Wang via swift-dev]

I want to submit some patches but I’m not sure whether I should apply some 
@_attributes(like @_transparent and @_semantics) that I see in stdlib to my API 
because I don’t know their meanings. Where are they documented?
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Linker script on Linux

[Joe Groff via swift-dev]

> On Dec 30, 2015, at 1:24 AM, Luke Howard via swift-dev  
> wrote:
> 
> Per [SR-404], anything that consumed libFoundation could not dynamically cast 
> to a Foundation protocol because the build script was missing the magic 
> swift.ld linker script to advertise the start of the protocol conformances 
> table.

Is it possible that the library is getting linked by clang instead of swiftc? I 
would expect the swiftc driver to pass the linker script down to ld (but maybe 
it's not).

> (There’s also some weird issue where dlsym() seems to return the previous 
> table if it can’t find one, but that’s a separate issue.)

Might be a runtime bug—are we looking up the symbol with RTLD_LOCAL?

-Joe

> 
> The build system is opaque enough that I’m not exactly sure how the linker is 
> driven when building shared libraries, but it would be great if the linker 
> script was added automagically.
> 
> — Luke
> --
> www.lukehoward.com 
> soundcloud.com/lukehoward
> 
> 
> ___
> 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] Where are @_attributes documented?

[Joe Groff via swift-dev]

> On Dec 30, 2015, at 4:58 PM, Ling Wang via swift-dev  
> wrote:
> 
> I want to submit some patches but I’m not sure whether I should apply some 
> @_attributes(like @_transparent and @_semantics) that I see in stdlib to my 
> API because I don’t know their meanings.

If it starts with an underscore, the answer is always "no, unless you're the 
standard library". These attributes are compiler-internal and not intended to 
be used by user code. We reserve the right to change them with reckless abandon.

> Where are they documented?

Some are documented in the compiler's 'doc/' subdirectory in various places.

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

Re: [swift-dev] Linker script on Linux

[Luke Howard via swift-dev]

> On 31 Dec 2015, at 12:33 PM, Joe Groff  wrote:
> 
> 
>> On Dec 30, 2015, at 1:24 AM, Luke Howard via swift-dev > > wrote:
>> 
>> Per [SR-404], anything that consumed libFoundation could not dynamically 
>> cast to a Foundation protocol because the build script was missing the magic 
>> swift.ld linker script to advertise the start of the protocol conformances 
>> table.
> 
> Is it possible that the library is getting linked by clang instead of swiftc? 
> I would expect the swiftc driver to pass the linker script down to ld (but 
> maybe it's not).

You’re right, clang is being called to link. Changing to swiftc will be a bit 
more intrusive to the Foundation build scripts (at given my mediocre knowledge 
of Python) but is probably the right answer.

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Luke Howard via swift-dev]

> On 31 Dec 2015, at 11:25 AM, Luke Howard via swift-dev  
> wrote:
> 
>> I really want to merge in the rest of the coders; so lets go ahead and omit 
>> the mangling stuff and leave it just as the Foundation classes . That will 
>> be a huge win in my book, it gives us something that is testable and 
>> functional enough to do some pretty impressive demonstrations of archiving.
> 
> OK, the version I’ve pushed now removes the code that was poking into runtime 
> structures but still uses dlopen()/the metadata accessor for 
> NSClassFromString(). Tests verify on OS X and Linux (with compiler fix).
> 
> If you want to change this further to use a static mapping table, go for it, 
> but I’d rather focus my time on getting the appropriate API into stdlib.

As a compromise how about a:

* swift_getTypeByName() API that only takes demangled names
* NSClassFromString()/NSStringFromClass() remain internal and hard fail with 
nested classes/generics
* We decide what to do about nested class interop later (is changing the Darwin 
behaviour something that would even be on the table?)

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Philippe Hausler via swift-dev]

> On Dec 30, 2015, at 6:57 PM, Luke Howard  wrote:
> 
> 
>> On 31 Dec 2015, at 11:25 AM, Luke Howard via swift-dev  
>> wrote:
>> 
>>> I really want to merge in the rest of the coders; so lets go ahead and omit 
>>> the mangling stuff and leave it just as the Foundation classes . That will 
>>> be a huge win in my book, it gives us something that is testable and 
>>> functional enough to do some pretty impressive demonstrations of archiving.
>> 
>> OK, the version I’ve pushed now removes the code that was poking into 
>> runtime structures but still uses dlopen()/the metadata accessor for 
>> NSClassFromString(). Tests verify on OS X and Linux (with compiler fix).
>> 
>> If you want to change this further to use a static mapping table, go for it, 
>> but I’d rather focus my time on getting the appropriate API into stdlib.
> 
> As a compromise how about a:
> 
> * swift_getTypeByName() API that only takes demangled names
> * NSClassFromString()/NSStringFromClass() remain internal and hard fail with 
> nested classes/generics
> * We decide what to do about nested class interop later (is changing the 
> Darwin behaviour something that would even be on the table?)
> 
> — Luke

I think those are all pretty reasonable. The pipeline for changes is 
bi-directional; however it will have to get reviewed by the component owner and 
undergo our process to change API behavior internally. I am fairly certain that 
this is an edge case that hasn’t even been thought of and I would think that 
the rest of the Foundation team will be very apt to nail this down so we don’t 
have to worry about backwards compatibility problems that using the mangled 
name might incur in the future.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Luke Howard via swift-dev]

> On 31 Dec 2015, at 2:10 PM, Philippe Hausler  wrote:
> 
> I think those are all pretty reasonable. The pipeline for changes is 
> bi-directional; however it will have to get reviewed by the component owner 
> and undergo our process to change API behavior internally. I am fairly 
> certain that this is an edge case that hasn’t even been thought of and I 
> would think that the rest of the Foundation team will be very apt to nail 
> this down so we don’t have to worry about backwards compatibility problems 
> that using the mangled name might incur in the future.

Right, NB the behaviour is really in libobjc’s objc_lookUpClass/class_getName.

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

Re: [swift-dev] Where are @_attributes documented?

[Ling Wang via swift-dev]

Yes I’m submitting patches to stdlib. Thanks for pointing me to the doc folder.

> On Dec 30, 2015, at 7:35 PM, Joe Groff  wrote:
> 
> 
>> On Dec 30, 2015, at 4:58 PM, Ling Wang via swift-dev  
>> wrote:
>> 
>> I want to submit some patches but I’m not sure whether I should apply some 
>> @_attributes(like @_transparent and @_semantics) that I see in stdlib to my 
>> API because I don’t know their meanings.
> 
> If it starts with an underscore, the answer is always "no, unless you're the 
> standard library". These attributes are compiler-internal and not intended to 
> be used by user code. We reserve the right to change them with reckless 
> abandon.
> 
>> Where are they documented?
> 
> Some are documented in the compiler's 'doc/' subdirectory in various places.
> 
> -Joe

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