Is interesting that the topic is going in this direction. The question
of "how an API “gets finalized” it's been something that has been a
little worrying for a while. The fact that a change in Swift goes from
Proposal to Oficial, part of the lang *for ever*, has bitten us in the
past already. My u
> On Jan 13, 2018, at 1:40 PM, Erica Sadun wrote:
>
>
>
>> On Jan 9, 2018, at 10:22 PM, Brent Royal-Gordon via swift-evolution
>> wrote:
>> If we can't do this, I think we should call it something like `PairArray` or
>> `KeyValueArray`
>
> Or "KeyValueList", which avoids both "Dictionary"
I should have been more clear: APIs that we add through Swift Evolution
would continue to be permanent additions to the language just as they are
today. I was not suggesting otherwise. However, the underlying
behind-the-scenes ABI-related aspects of their implementations would
initially be malleabl
Hi Nevin,
I think this is an interesting perspective. For me it begets the question of
how an API “gets finalized”. Currently anything that goes through the Swift
Evolution proposal process that gets ratified is considered an official change
to the language and Standard Library. That feels l
For some OS vendors it may be feasible to have multiple Swift runtimes
installed on the system to be used by different apps. That, however, is not an
option if you actually want the libraries in the OS — in the case of macOS and
iOS the OS frameworks — to actually use Swift themselves. At the
Alternatively, from a different perspective, rather than adding a new
ABI-unstable library that gets bundled with apps, another way to look at it
is that we already *have* an ABI-unstable library that gets bundled with
apps. So we can instead think about introducing a new library with a stable
ABI,
This. I asked that already and they not understand me very well.
I see no reason for each app to have its own version of "deprecated lib".
Also we can keep the libswiftCore_4.1.dylib, libswiftCore_5.0.dylib,
libswiftCore_5.1.dylib etc on the SO too. The default target must be
libswiftCore.dylib,
Pardon my lack of knowledge in this area, but is there not also a 3rd option
available?
(C) Split libswiftCore.dylib into two dylibs, both at the OS level. The
*Deprecated.dylib would only be included when the application binary was
compiled using a special -using-deprecated flag that signifies
On Mon, Jan 8, 2018 at 4:29 PM, Ben Cohen via swift-evolution
wrote:
> There exists in the standard library a type `DictionaryLiteral` that deserves
> naming re-consideration before we declare ABI Stability, because it’s
> confusingly misnamed, being neither a Dictionary (it doesn’t provide
> k
> On Jan 12, 2018, at 11:23 PM, Chris Lattner wrote:
>
> On Jan 12, 2018, at 4:43 PM, Ted Kremenek wrote:
>> Hi Chris,
>>
>> Instead of responding to each of your point bit-by-bit, I’ll try a different
>> tactic to explain my reasoning — which may be wrong — by explaining how I
>> see thing
> I agree. The major motivation from my side isn’t the code size reduction, it
> is that we’ll have a better and brighter future with more clarity and less
> weird cruft left over - like the “DictionaryLiteral” type that sparked this
> whole thread. Have you looked at it? It’s crazy. :-)
+1
> On Jan 9, 2018, at 10:22 PM, Brent Royal-Gordon via swift-evolution
> wrote:
> If we can't do this, I think we should call it something like `PairArray` or
> `KeyValueArray`
Or "KeyValueList", which avoids both "Dictionary" and "Array" words.
-- E
___
Why is that a problem? Despite referring to it as the “unstable” half, if we
just put deprecated stuff in it, it would still be stable and should work for
that.
You are right that things would be more complicated if it is used as a “staging
ground” for features that eventually make it into cor
One major drawback of splitting Coe library, is that despite having a stable
ABI, you break the possibility to include binary frameworks inside an
application unless they both link on the same version of
libswiftCoreDeprecated.dylib (assuming libswiftCoreDeprecated.dylib has not a
stable ABI, e
On Jan 12, 2018, at 4:43 PM, Ted Kremenek wrote:
> Hi Chris,
>
> Instead of responding to each of your point bit-by-bit, I’ll try a different
> tactic to explain my reasoning — which may be wrong — by explaining how I see
> things top down with the tradeoffs they incur. I’m going to say a bunc
Hi Xiaodi,
It’s an interesting suggestion. My inclination is that seeding prototype APIs
would be better done via source package managers, and not as binary frameworks.
But they are two different approaches to the same problem and it is an
interesting idea.
I’d like to first focus, however,
One point to bring up is that what you call libswiftCoreDeprecated.dylib
can be the place that future APIs live until they’re sufficiently mature.
I highly doubt that additions to the Swift standard library past 5.0 will
all be fully baked on arrival, and having everything carved into stone the
mo
Hi Chris,
Instead of responding to each of your point bit-by-bit, I’ll try a different
tactic to explain my reasoning — which may be wrong — by explaining how I see
things top down with the tradeoffs they incur. I’m going to say a bunch of
things I know *you* know, but others are on this threa
For people who don’t read all the way down, here is the gist of what Chris is
saying:
> 1. The vast majority of the standard library goes into the OS. This includes
> all the string, array, and other stuff people use.
> 2. The deprecated wrappers and obscure APIs go into a new module, and that
> On Jan 11, 2018, at 12:22 AM, Ted Kremenek wrote:
>
>
>
>> On Jan 9, 2018, at 11:48 AM, Chris Lattner via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>>> IMO that isn’t a question we should be asking any more except in cases
>>> where an existing implementation is caus
> On Jan 11, 2018, at 12:01 AM, Ted Kremenek wrote:
>> The nice thing about this is that only people who use these things would
>> have to pay the cost, and you can directly message this by deprecating all
>> the stuff in it. Think about it as an overlay for the Swift standard
>> library :-)
>
> On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution
> wrote:
>
> Ok, I understand that (among all the other things going on that are clearly
> more important) revamping this is probably not the highest priority thing to
> do. That said, it would be really unfortunate to carry a
> On Jan 9, 2018, at 11:48 AM, Chris Lattner via swift-evolution
> wrote:
>
>> IMO that isn’t a question we should be asking any more except in cases where
>> an existing implementation is causing active harm. Which, confusing name
>> aside, this type isn’t (aside from API sprawl I guess).
>
Right. When I say “statically link” here, I really mean “put the .dylib for
the library into the app bundle”. That’s what happens with Swift today. It
can be important to share that code between apps and appex’s for example.
-Chris
> On Jan 10, 2018, at 5:02 PM, Wallacy wrote:
>
> If I und
If I understand this correctly. This is exactly the same argument in favor
to maintain the ABI unstable and always bundle the standard library and the
runtime with the app.
Another alternative is, not only, separate the standard library on small
pieces, but also dynamic link this specific version
Excellent Idea!
I am all for this. It shouldn’t be too complicated to add a second implicit
import and only code that is actually using this stuff will have increased code
size.
> On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution
> wrote:
>
> Disclaimer: I’m reordering your comm
> On Jan 10, 2018, at 1:52 AM, Ian Partridge wrote:
>
> On 10 January 2018 at 06:29, Chris Lattner via swift-evolution
> wrote:
>> Ok, I understand that (among all the other things going on that are clearly
>> more important) revamping
>> this is probably not the highest priority thing to do.
On 10 January 2018 at 06:29, Chris Lattner via swift-evolution
wrote:
> Ok, I understand that (among all the other things going on that are clearly
> more important) revamping
> this is probably not the highest priority thing to do. That said, it would
> be really unfortunate to carry
> around
Disclaimer: I’m reordering your comments below to suit my nefarious purposes:
:-)
On Jan 9, 2018, at 3:48 PM, Ben Cohen wrote:
>> More to the point though, this seems like an implementation detail of
>> Mirrors. What is the plan for Mirrors + ABI stability?
>>
>
> Absent a proposal to change
> On Jan 9, 2018, at 9:04 PM, Brent Royal-Gordon via swift-evolution
> wrote:
>
> The problem is that this isn't currently expressible in the type system. If
> we can, I would actually support including some kind of unprincipled private
> hack so we could say `where Element: _AnyTupleOfTwo`.
Oops. Kindly disregard my previous emails. Ben was kind enough to point out
to me that I was confusing dictionary literals with DictionaryLiteral
On Tue, Jan 9, 2018 at 8:56 PM, Ben Cohen <> wrote:
> Hi Charles,
>
> The naming issue strikes again :)
>
> Your code is making use of dictionary liter
> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution
> wrote:
>
> I’m canvassing for opinions on what it ought to be called. Some suggestions
> so far:
>
> - `AssociationCollection`: Following the term of art from some other
> languages. Slightly obscure-sounding to developers not alr
Hi Nevin (et al)
Here's the relevant section of my code. It's from a protocol I use called
"ParameterSet" to extend OptionSets to contain small numbers (like an Enum
with an associated type, but all the data is stored in the UInt). Wouldn't
be my first choice to share, as it breaks KISS. Anyhow, t
On Tue, Jan 9, 2018 at 9:27 PM, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:
> I think this type might become more useful if we find a good name for it
> and better document it. For example, it is a natural fit for parameter list
> of Chris’ callable type proposal.
>
> Since
I think this type might become more useful if we find a good name for it and
better document it. For example, it is a natural fit for parameter list of
Chris’ callable type proposal.
Since this type accepts duplicate “keys” and does not provide key-based lookup,
the first thing that deserves a
On Tue, Jan 9, 2018 at 7:47 PM, char...@charlesism.com <
charlesism@gmail.com> wrote:
> I used a DictionaryLiteral only yesterday, and it turned what would have a
> typically unreadable array of Structs into something much more elegant. I'm
> pretty sure the only reason Literals (of all variet
I used a DictionaryLiteral only yesterday, and it turned what would have a
typically unreadable array of Structs into something much more elegant. I'm
pretty sure the only reason Literals (of all varieties) aren't used more often
is because Swift programmers don't realize they are available and
> On Jan 9, 2018, at 11:48 AM, Chris Lattner wrote:
>
>> On Jan 9, 2018, at 10:23 AM, Ben Cohen wrote:
The old name can live on indefinitely via a typealias (which has no ABI
consequences, so could be retired at a later date once everyone has had
plenty of time to addres
> On Jan 9, 2018, at 10:23 AM, Ben Cohen wrote:
>>>
>>> The old name can live on indefinitely via a typealias (which has no ABI
>>> consequences, so could be retired at a later date once everyone has had
>>> plenty of time to address the deprecation warnings). Removing it as not
>>> carrying i
> On Jan 9, 2018, at 8:16 AM, Zach Waldowski via swift-evolution
> wrote:
>
> I'm not sure a valid use case by a third party makes it hold its weight for
> inclusion in the stdlib. Reproducing its feature set is extremely trivial,
> and would probably allow you to hint the implementation deta
> On Jan 8, 2018, at 10:12 PM, Chris Lattner wrote:
>
>
>> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>> There exists in the standard library a type `DictionaryLiteral` that
>> deserves naming re-consideration before we declare ABI
> Le 9 janv. 2018 à 18:18, Nate Cook a écrit :
>
>> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>>>
>>> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution
>>> mailto:swift-evolution@swift.org>> a écrit :
>>>
>>> I'm
Now that I think of it, this type would be great for storing results from a SQL
query run on a database, for instance.
This is a valid SQL statement:
SELECT `firstname`, `lastname`, `firstname` FROM `employees`;
Note there is two copies of “firstname”. Don’t ask why. All that matters is
that i
How about renaming DictionaryLiteral to Row, TabularRow or TableRow?
I think most developers are familiar with the idea that a table row contains
multiple columns (in specific order), and each column has a name and a value
(key/value).
Some other name suggestions:
- Record (kind of an old name
> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution
> wrote:
>
>>
>> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution
>> mailto:swift-evolution@swift.org>> a écrit :
>>
>> I'm not sure a valid use case by a third party makes it hold its weight for
>> inclusion in the s
> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution
> a écrit :
>
> I'm not sure a valid use case by a third party makes it hold its weight for
> inclusion in the stdlib.
You're definitely right, and that's why I wrote with the most humble tone I
could.
Yet, the design of the stdl
I'm not sure a valid use case by a third party makes it hold its weight
for inclusion in the stdlib. Reproducing its feature set is extremely
trivial, and would probably allow you to hint the implementation details
better for your use case.
Zach
z...@waldowski.me
On Tue, Jan 9, 2018, at 2:12 AM,
> Le 9 janv. 2018 à 08:06, Gwendal Roué via swift-evolution
> a écrit :
>
>
>> Le 9 janv. 2018 à 06:40, Nevin Brackett-Rozinsky via swift-evolution
>> mailto:swift-evolution@swift.org>> a écrit :
>>
>> The ulterior question of whether preserving “DictionaryLiteral” is
>> worthwhile, is appa
On Jan 8, 2018, at 11:07 PM, Nate Cook wrote:
>>>
>>> The old name can live on indefinitely via a typealias (which has no ABI
>>> consequences, so could be retired at a later date once everyone has had
>>> plenty of time to address the deprecation warnings). Removing it as not
>>> carrying its
Nate
> On Jan 9, 2018, at 12:12 AM, Chris Lattner via swift-evolution
> wrote:
>
>
>> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution
>> wrote:
>> There exists in the standard library a type `DictionaryLiteral` that
>> deserves naming re-consideration before we declare ABI Stabi
> Le 9 janv. 2018 à 06:40, Nevin Brackett-Rozinsky via swift-evolution
> a écrit :
>
> The ulterior question of whether preserving “DictionaryLiteral” is
> worthwhile, is apparently out of scope. Personally, I have a hard time
> imagining a compelling use-case outside of the standard library,
> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution
> wrote:
> There exists in the standard library a type `DictionaryLiteral` that deserves
> naming re-consideration before we declare ABI Stability, because it’s
> confusingly misnamed, being neither a Dictionary (it doesn’t provide
>
On Tue, Jan 9, 2018 at 00:40 Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 11:53 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Thank you for the clarification. It occurred to me in the shower that
>> this might be the cas
On Mon, Jan 8, 2018 at 11:53 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:
> Thank you for the clarification. It occurred to me in the shower that this
> might be the case, and that I was entirely mistaken as to what we were
> talking about.
>
> Yes, then, I wholeheartedly
Thank you for the clarification. It occurred to me in the shower that this
might be the case, and that I was entirely mistaken as to what we were
talking about.
Yes, then, I wholeheartedly agree on this point. Out of curiosity, why are
there source stability issues to 'typealias DictionaryLiteral
> On Jan 8, 2018, at 9:07 PM, Xiaodi Wu wrote:
>
> While there’s nothing specifically to do with a dictionary, it is a literal
> in at least one essential respect. Like other literals, it doesn’t have a
> type, but values that are expressed by them do acquire a type given the
> context.
This
While there’s nothing specifically to do with a dictionary, it is a literal
in at least one essential respect. Like other literals, it doesn’t have a
type, but values that are expressed by them do acquire a type given the
context.
Yes, it's not a dictionary, but neither is an integer literal an in
> On Jan 8, 2018, at 6:29 PM, Ben Cohen via swift-evolution
> wrote:
>
> There exists in the standard library a type `DictionaryLiteral` that deserves
> naming re-consideration before we declare ABI Stability, because it’s
> confusingly misnamed, being neither a Dictionary (it doesn’t provide
> On Jan 8, 2018, at 5:08 PM, Karl Wagner wrote:
>
>
>
>> On 9. Jan 2018, at 01:29, Ben Cohen via swift-evolution
>> wrote:
>>
>> There exists in the standard library a type `DictionaryLiteral` that
>> deserves naming re-consideration before we declare ABI Stability, because
>> it’s conf
> On 9. Jan 2018, at 01:29, Ben Cohen via swift-evolution
> wrote:
>
> There exists in the standard library a type `DictionaryLiteral` that deserves
> naming re-consideration before we declare ABI Stability, because it’s
> confusingly misnamed, being neither a Dictionary (it doesn’t provide
60 matches
Mail list logo
