Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Brent Royal-Gordon via swift-evolution]

> 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" and "Array" words.


I specifically want "Array" in the name, because this type has the same 
semantics as an array:

* RandomAccessCollection
* Contiguous, zero-based Int indices
* Isn't currently, but could be, MutableCollection and 
RangeReplaceableCollection

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

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 like “finalized” to me, 
unless we want to introduce some new affordances to the process that allow us 
to introduce new APIs that are clearly going through a trial.  I think that’s a 
very interested idea (which is one Xiaodi proposed), but that’s not something 
we have today.

On this thread we are talking about APIs that have been in the Standard Library 
for a while, and largely predate the Swift Evolution process.  What makes them 
less finalized versus other APIs with similar heritage?  These APIs are in use, 
albeit Chris points out that they are (most likely) uncommonly used.  A core 
deliverable of ABI stability, however, is that the majority of the Standard 
Library is in a binary stable form.  The only APIs I think we can consider 
candidates for a “deprecated” dylib that gets embedded in the app are “leaf” 
APIs that are uncommonly used by clients and not relied upon by other parts of 
the Standard Library that are commonly used by clients.  Practically speaking, 
however, I’m not convinced that set is so large to add the 
complexity/engineering cost/time of creating this separate dylib right now.  
Those APIs can’t get ripped out right now — after all they’ve been in there for 
a while and we’re not deprecating them because there aren’t alternatives that 
exist yet anyway.  Thus these APIs need to continue to exist, and the benefits 
to me to create this separate dylib for those old “warty” APIs that we may — 
one day — want to replace seems marginal.

I do think the idea of having a way to add *new* ABI-unstable APIs is very 
interesting, but I think the root of this discussion comes from talking about 
APIs that have been around for a while but feel like potential warts as we 
approach ABI stability.  I hate to say it, but there will be warts regardless.  
There’s a lot to do for ABI stability — it’s making good progress — but not 
every last change we may have wanted to do will get all the attention we may 
have originally hoped it would.  Getting ABI stability done for Swift 5 is 
about prioritization and best effort, which includes accepting that not 
everything is going to be perfect.

Ted

> On Jan 15, 2018, at 1:04 PM, Nevin Brackett-Rozinsky 
>  wrote:
> 
> 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, which can be distributed with the OS.
> 
> That way, as each piece of the existing standard library gets finalized, we 
> can move it into the new ABI-stable library. Some pieces (eg. Mirror) will 
> never make the jump and can be phased out eventually. And when future 
> proposals make additions to the standard library, they can begin life in the 
> original, existing, non-ABI-stable library.
> 
> The net effect is the same as what we have been discussing, but a shift in 
> viewpoint makes it clear that the ABI-stable library is the new thing we are 
> adding, and the existing standard library can continue to serve a valuable 
> purpose going forward.
> 
> Nevin
> 
> 
> 
> On Sun, Jan 14, 2018 at 9:04 PM, Ted Kremenek via swift-evolution 
> > wrote:
> 
> 
> > 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 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 
> >> thread and I’ll state things for end-to-end clarity.
> >
> > Sounds good.
> >
> >> It seems to me that we are talking about two possible scenarios: (1) the 
> >> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
> >> libswiftCore.dylib into two dylibs, one which includes some of the 
> >> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits 
> >> we will see with both scenarios, and see where the mismatch in our 
> >> “talking past each other” is happening.
> >
> > Right.
> >
> >> In both cases (A) and (B), with ABI stability the Standard Library has the 
> >> option to ship in the OS.  Thus applications using Swift on (say) iOS 
> >> would no longer need to include libswiftCore.dylib in the app when 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

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 end of the 
day the frameworks in the framework stack have to be using the same Swift 
runtime in order to have Swift APIs, pass Swift objects around that are managed 
by the runtime, etc.

The Swift runtime was designed to actually allow the coexistence of two Swift 
runtimes: one for apps built before ABI stability that include a copy of the 
Swift runtime for their own use, and one for ABI stability that can be used 
both by the OS frameworks as well as apps built with the same version of Swift 
(or later) that had ABI stability.  In the case of runtime coexistence (which 
is to not break older Swift apps that aren’t rebuilt with a newer compiler) 
essentially the two runtimes are designed to essentially ignore each other.

> On Jan 15, 2018, at 11:48 AM, Wallacy via swift-evolution 
>  wrote:
> 
> 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, but if need to use a specific feature on 
> libswiftCore_4.1.dylib why not.
> 
> Em seg, 15 de jan de 2018 às 16:54, Jacob Williams via swift-evolution 
> > escreveu:
> 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 this app needs 
> at least one of the deprecated APIs? Then the code signing verification you 
> mention wouldn’t be a part of the apps that use deprecated APIs.
> 
> If this is not possible because all OS-level .dylibs MUST be included for 
> whatever reason then just disregard me, as I’m not an expert on this area of 
> Swift.
> 
> 
>> On Jan 12, 2018, at 5:43 PM, Ted Kremenek via swift-evolution 
>> > 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 bunch 
>> of things I know *you* know, but others are on this thread and I’ll state 
>> things for end-to-end clarity.
>> 
>> It seems to me that we are talking about two possible scenarios: (1) the 
>> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
>> libswiftCore.dylib into two dylibs, one which includes some of the 
>> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits 
>> we will see with both scenarios, and see where the mismatch in our “talking 
>> past each other” is happening.
>> 
>> In both cases (A) and (B), with ABI stability the Standard Library has the 
>> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
>> no longer need to include libswiftCore.dylib in the app when running on an 
>> OS that shipped with the Standard Library.
>> 
>> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
>> (B):
>> 
>> 
>> (A) Status quo: Keep shipping everything in libswiftCore.dylib
>> 
>> - Applications running on an OS with the Standard Library would no longer 
>> have *any* of the currently libswift*.dylib’s embedded inside the 
>> application bundle because they would just use the one in the OS.
>> 
>> - One benefit of using libswift*.dylibs in the OS as opposed to those 
>> embedded inside the app bundle is that there is a non-neglible startup time 
>> improvement, as the code signing verification that happens when an app 
>> launches would be faster as it would not need to verify each of these dylibs 
>> that were previously embedded in the app.  We should consider this the new 
>> baseline for app startup time for an app running on an OS with an ABI stable 
>> Standard Library.
>> 
>> - We continue to support the deprecated APIs for some time, possibly 
>> indefinitely, even when better alternatives come around.
>> 
>> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the 
>> app bundle
>> 
>> In the second scenario, we split out the deprecated APIs into a separate 
>> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the 
>> following characteristics:
>> 
>> - Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
>> when running on an OS that had an ABI-stable Standard 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nevin Brackett-Rozinsky via swift-evolution]

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, which can be distributed with the OS.

That way, as each piece of the existing standard library gets finalized, we
can move it into the new ABI-stable library. Some pieces (eg. Mirror) will
never make the jump and can be phased out eventually. And when future
proposals make additions to the standard library, they can begin life in
the original, existing, non-ABI-stable library.

The net effect is the same as what we have been discussing, but a shift in
viewpoint makes it clear that the ABI-stable library is the new thing we
are adding, and the existing standard library can continue to serve a
valuable purpose going forward.

Nevin



On Sun, Jan 14, 2018 at 9:04 PM, Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> > 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 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
> thread and I’ll state things for end-to-end clarity.
> >
> > Sounds good.
> >
> >> It seems to me that we are talking about two possible scenarios: (1)
> the status quo of keeping everything in libswiftCore.dylib or (2) splitting
> libswiftCore.dylib into two dylibs, one which includes some of the
> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits
> we will see with both scenarios, and see where the mismatch in our “talking
> past each other” is happening.
> >
> > Right.
> >
> >> In both cases (A) and (B), with ABI stability the Standard Library has
> the option to ship in the OS.  Thus applications using Swift on (say) iOS
> would no longer need to include libswiftCore.dylib in the app when running
> on an OS that shipped with the Standard Library.
> >
> > Right.  Please keep in mind that both approaches also eliminate all the
> overlay dylibs for those apps, and both approaches put the vast majority of
> the stdlib code into the OS as well.  The ‘deprecated’ dylib is probably
> going to be comparatively small.
> >
> >> With that in mind, here are the tradeoffs as I see between scenarios
> (A) and (B):
> >>
> >> (A) Status quo: Keep shipping everything in libswiftCore.dylib
> >>
> >> - Applications running on an OS with the Standard Library would no
> longer have *any* of the currently libswift*.dylib’s embedded inside the
> application bundle because they would just use the one in the OS.
> >
> > Right.
> >
> >> - One benefit of using libswift*.dylibs in the OS as opposed to those
> embedded inside the app bundle is that there is a non-neglible startup time
> improvement, as the code signing verification that happens when an app
> launches would be faster as it would not need to verify each of these
> dylibs that were previously embedded in the app.  We should consider this
> the new baseline for app startup time for an app running on an OS with an
> ABI stable Standard Library.
> >
> > This happens with both models.  Refer back to the dyld optimization WWDC
> talk by Nick and Louis 2-3 years ago.  The big problem with Swift for
> startup time is that it adds half a dozen (or more) dylibs to your app
> bundle.  In the talk they make it clear that adding a single dylib is not a
> big deal, it is adding a bunch of dylibs that is the problem, particularly
> if they have interdependencies between them.
>
> Right — it is the large volume of dylibs that is the problem.
>
> >
> > Neither approach presents this performance problem.
>
> Agreed — in practice neither scenario is much different.
>
> >
> > Further, if it were important to solve this startup time problem, it is
> straight-forward to solve it for apps that do want to deploy backward
> (which will be almost all of them in NMOS).  You’d do this by merging all
> the dylibs into a single one in the app bundle instead of leaving them to
> be independently resolved at load time.
> >
> >> - We continue to support the deprecated APIs for some time, possibly
> indefinitely, even when better alternatives come around.
> >
> > Agreed.
> >
> >> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in
> the app bundle
> >>
> >> In the second scenario, we split out the deprecated APIs into a
> separate dylib, say libswiftCoreDeprecated.dylib.  That solution would have
> the following characteristics:
> >>
> >> - Like scenario (A), app bundles would not need to embed
> libswiftCore.dylib when running on an OS that had an ABI-stable 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Wallacy via swift-evolution]

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, but if need to use a specific feature on
libswiftCore_4.1.dylib why not.

Em seg, 15 de jan de 2018 às 16:54, Jacob Williams via swift-evolution <
swift-evolution@swift.org> escreveu:

> 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 this app
> needs at least one of the deprecated APIs? Then the code signing
> verification you mention wouldn’t be a part of the apps that use deprecated
> APIs.
>
> If this is not possible because all OS-level .dylibs MUST be included for
> whatever reason then just disregard me, as I’m not an expert on this area
> of Swift.
>
>
> On Jan 12, 2018, at 5:43 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> 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 bunch of things I know *you* know, but others are on this
> thread and I’ll state things for end-to-end clarity.
>
> It seems to me that we are talking about two possible scenarios: (1) the
> status quo of keeping everything in libswiftCore.dylib or (2) splitting
> libswiftCore.dylib into two dylibs, one which includes some of the
> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits
> we will see with both scenarios, and see where the mismatch in our “talking
> past each other” is happening.
>
> In both cases (A) and (B), with ABI stability the Standard Library has the
> option to ship in the OS.  Thus applications using Swift on (say) iOS would
> no longer need to include libswiftCore.dylib in the app when running on an
> OS that shipped with the Standard Library.
>
> With that in mind, here are the tradeoffs as I see between scenarios (A)
> and (B):
>
>
> (A) Status quo: Keep shipping everything in libswiftCore.dylib
>
> - Applications running on an OS with the Standard Library would no longer
> have *any* of the currently libswift*.dylib’s embedded inside the
> application bundle because they would just use the one in the OS.
>
> - One benefit of using libswift*.dylibs in the OS as opposed to those
> embedded inside the app bundle is that there is a non-neglible startup time
> improvement, as the code signing verification that happens when an app
> launches would be faster as it would not need to verify each of these
> dylibs that were previously embedded in the app.  We should consider this
> the new baseline for app startup time for an app running on an OS with an
> ABI stable Standard Library.
>
> - We continue to support the deprecated APIs for some time, possibly
> indefinitely, even when better alternatives come around.
>
> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in
> the app bundle
>
> In the second scenario, we split out the deprecated APIs into a separate
> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the
> following characteristics:
>
> - Like scenario (A), app bundles would not need to embed
> libswiftCore.dylib when running on an OS that had an ABI-stable Standard
> Library.
>
> - Compared to scenario (A), the OS shipping the Standard Library would
> have a slightly smaller libswiftCore.dylib that didn’t carry the bits for
> the deprecated APIs.  This would be a benefit in the code size for the OS,
> but not for the app itself.
>
> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib
> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside
> their app bundle.  Compared to the new baseline I mentioned in (A), such
> apps would have a launch time regression once they started using any API in
> the libSwiftCoreDeprecated.dylib because code signing would need to verify
> the dylib, just like it does today with the libswiftCore.dylib that is
> embedded in every application.  They would also be slightly larger because
> the app bundle has the burden of hosting libswiftCoreDeprecated.dylib,
> instead of compared to scenario (A) where the implementations of the
> deprecated APIs are hosted by the libswiftCore.dylib that ships in the OS.
>
> - Because of binary compatibility concerns, after Swift 5 we would *never*
> be able to “take out” any further APIs from libswiftCore.dylib and put them
> in libswiftCoreDeprecated.dylib.  This factorization can only happen once.
>
> - There is some slight additional complexity added to the compiler and
> 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Jacob Williams via swift-evolution]

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 this app needs 
at least one of the deprecated APIs? Then the code signing verification you 
mention wouldn’t be a part of the apps that use deprecated APIs.

If this is not possible because all OS-level .dylibs MUST be included for 
whatever reason then just disregard me, as I’m not an expert on this area of 
Swift.

> On Jan 12, 2018, at 5:43 PM, Ted Kremenek via swift-evolution 
>  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 bunch of 
> things I know *you* know, but others are on this thread and I’ll state things 
> for end-to-end clarity.
> 
> It seems to me that we are talking about two possible scenarios: (1) the 
> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
> libswiftCore.dylib into two dylibs, one which includes some of the 
> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits we 
> will see with both scenarios, and see where the mismatch in our “talking past 
> each other” is happening.
> 
> In both cases (A) and (B), with ABI stability the Standard Library has the 
> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
> no longer need to include libswiftCore.dylib in the app when running on an OS 
> that shipped with the Standard Library.
> 
> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
> (B):
> 
> 
> (A) Status quo: Keep shipping everything in libswiftCore.dylib
> 
> - Applications running on an OS with the Standard Library would no longer 
> have *any* of the currently libswift*.dylib’s embedded inside the application 
> bundle because they would just use the one in the OS.
> 
> - One benefit of using libswift*.dylibs in the OS as opposed to those 
> embedded inside the app bundle is that there is a non-neglible startup time 
> improvement, as the code signing verification that happens when an app 
> launches would be faster as it would not need to verify each of these dylibs 
> that were previously embedded in the app.  We should consider this the new 
> baseline for app startup time for an app running on an OS with an ABI stable 
> Standard Library.
> 
> - We continue to support the deprecated APIs for some time, possibly 
> indefinitely, even when better alternatives come around.
> 
> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the 
> app bundle
> 
> In the second scenario, we split out the deprecated APIs into a separate 
> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the 
> following characteristics:
> 
> - Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
> when running on an OS that had an ABI-stable Standard Library.
> 
> - Compared to scenario (A), the OS shipping the Standard Library would have a 
> slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
> deprecated APIs.  This would be a benefit in the code size for the OS, but 
> not for the app itself.
> 
> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside their 
> app bundle.  Compared to the new baseline I mentioned in (A), such apps would 
> have a launch time regression once they started using any API in the 
> libSwiftCoreDeprecated.dylib because code signing would need to verify the 
> dylib, just like it does today with the libswiftCore.dylib that is embedded 
> in every application.  They would also be slightly larger because the app 
> bundle has the burden of hosting libswiftCoreDeprecated.dylib, instead of 
> compared to scenario (A) where the implementations of the deprecated APIs are 
> hosted by the libswiftCore.dylib that ships in the OS.
> 
> - Because of binary compatibility concerns, after Swift 5 we would *never* be 
> able to “take out” any further APIs from libswiftCore.dylib and put them in 
> libswiftCoreDeprecated.dylib.  This factorization can only happen once.
> 
> - There is some slight additional complexity added to the compiler and build 
> system to support this spit of the Standard Library into multiple dylibs.  
> It’s not a huge concern but it does exist and it is not free both in terms of 
> implementing and maintaining.
> 
> - We continue to support the deprecated APIs for some time, possibly 
> indefinitely, even when better alternatives come around.  We *may* be able to 
> completely sunset these APIs by having a future version of the Swift compiler 
> simply refuse to 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Dmitri Gribenko via swift-evolution]

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 
> key-based lookup of values) nor a Literal.
>
> Instead, it’s just an immutable collection of key-value pairs you can create 
> _from_ a literal.

I was around when we were naming this type, and I don't think it is
misnamed.  However, I just read the documentation and I don't believe
it explains the intended use of the type, hence we have this
confusion.

The intended use case for DictionaryLiteral is to build DSLs.  Swift
provides types in the standard library that are efficient and lossless
representations for all literals, but are also useful as your
workhorse data types: string literal -- String, array literal --
Array, integer literal -- [U]Int64, kinda (there is some
dissatisfaction with integer literals since there is no type to
capture a >64 bit literal, which is useful for defining a bigint
type).  But there was no type that could capture a dictionary literal
in a lossless form, maintaining the order of items, not imposing
dictionary limitations like uniqueness or hashability of keys.

Therefore, we added DictionaryLiteral.  Yes, it did land together with
Mirrors in commit 50c6e936d4b94b9736a8d060ddf052ef1ba9c74d, but the
intent was that it is a generally useful library component unrelated
to Mirrors, and therefore we did not add any Mirror-related words to
the name (we couldn't nest it in Mirror because nested generics didn't
work at the time).  In fact you can see the comment in Mirrors.swift
that has been preserved to this date:

// This component could stand alone, but is used in Mirror's public interface.

Mirrors just *use* DictionaryLiteral to build a small DSL in the
initializer of Mirror, so that callers could call that initializer
representing Mirror's children with a nice intuitive syntax using a
dictionary literal.

Therefore, based on this intended use, I think that trying to hint
that this type is a general *collection* of any kind is a disservice
for users -- DictionaryLiteral wasn't intended to be a collection, and
it does not have performance characteristics anyone would reasonably
expect from it.  We could add more words to the name to paint it more
an "advanced tool shade", for example, CapturedDictionaryLiteral,
DictionaryLiteralSyntax or something along those lines, but I feel
like the impact of that to fix the confusion would be minimal.

Instead, I think the right way to fix the confusion is to adjust the
documentation to not claim that it is first and foremost a collection,
because currently documentation is only technically correct, but does
not explain the intended use of the type at all.

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

> 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 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 thread and I’ll state 
>> things for end-to-end clarity.
> 
> Sounds good.
> 
>> It seems to me that we are talking about two possible scenarios: (1) the 
>> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
>> libswiftCore.dylib into two dylibs, one which includes some of the 
>> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits 
>> we will see with both scenarios, and see where the mismatch in our “talking 
>> past each other” is happening.
> 
> Right.
> 
>> In both cases (A) and (B), with ABI stability the Standard Library has the 
>> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
>> no longer need to include libswiftCore.dylib in the app when running on an 
>> OS that shipped with the Standard Library.
> 
> Right.  Please keep in mind that both approaches also eliminate all the 
> overlay dylibs for those apps, and both approaches put the vast majority of 
> the stdlib code into the OS as well.  The ‘deprecated’ dylib is probably 
> going to be comparatively small.
> 
>> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
>> (B):
>> 
>> (A) Status quo: Keep shipping everything in libswiftCore.dylib
>> 
>> - Applications running on an OS with the Standard Library would no longer 
>> have *any* of the currently libswift*.dylib’s embedded inside the 
>> application bundle because they would just use the one in the OS.
> 
> Right.
> 
>> - One benefit of using libswift*.dylibs in the OS as opposed to those 
>> embedded inside the app bundle is that there is a non-neglible startup time 
>> improvement, as the code signing verification that happens when an app 
>> launches would be faster as it would not need to verify each of these dylibs 
>> that were previously embedded in the app.  We should consider this the new 
>> baseline for app startup time for an app running on an OS with an ABI stable 
>> Standard Library.
> 
> This happens with both models.  Refer back to the dyld optimization WWDC talk 
> by Nick and Louis 2-3 years ago.  The big problem with Swift for startup time 
> is that it adds half a dozen (or more) dylibs to your app bundle.  In the 
> talk they make it clear that adding a single dylib is not a big deal, it is 
> adding a bunch of dylibs that is the problem, particularly if they have 
> interdependencies between them.

Right — it is the large volume of dylibs that is the problem.

> 
> Neither approach presents this performance problem.

Agreed — in practice neither scenario is much different.

> 
> Further, if it were important to solve this startup time problem, it is 
> straight-forward to solve it for apps that do want to deploy backward (which 
> will be almost all of them in NMOS).  You’d do this by merging all the dylibs 
> into a single one in the app bundle instead of leaving them to be 
> independently resolved at load time.
> 
>> - We continue to support the deprecated APIs for some time, possibly 
>> indefinitely, even when better alternatives come around.
> 
> Agreed.
> 
>> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the 
>> app bundle
>> 
>> In the second scenario, we split out the deprecated APIs into a separate 
>> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the 
>> following characteristics:
>> 
>> - Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
>> when running on an OS that had an ABI-stable Standard Library.
>> 
>> - Compared to scenario (A), the OS shipping the Standard Library would have 
>> a slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
>> deprecated APIs.  This would be a benefit in the code size for the OS, but 
>> not for the app itself.
> 
> The code size is small so it doesn’t matter much either way,

Agreed.

> but this actually is an advantage for the average app.  Part of the point of 
> this is that most apps don’t use this stuff, so they wouldn’t include the 
> dylib at all.  There is no cost for them in either launch time or size.
> 
> To pick on Mirrors, the one example someone came up with is an API used by 
> the swift on server community.  I haven’t heard of anyone using them in an 
> iOS app (but of course I’m sure there is someone somewhere doing it :-)
> 
>> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
>> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside 
>> their app bundle.  Compared to the new baseline I mentioned in (A), such 
>> 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Georgios Moschovitis via swift-evolution]

> 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

One of the things that I like about Swift (vis-à-vis C++, Java, JavaScript etc) 
is that the Core team is not afraid to fix ‘historical mistakes’.
I think, Chris’ idea of a separate unstable/deprecated dylib provides an 
excellent platform for this practice to continue after ABI stability.

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Erica Sadun via swift-evolution]

> 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


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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

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 core though.

-Chris

> On Jan 13, 2018, at 4:58 AM, Jean-Daniel  wrote:
> 
> 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, else there is no point having it in the first place).
> 
> 
>> Le 13 janv. 2018 à 01:43, Ted Kremenek via swift-evolution 
>>  a écrit :
>> 
>> 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 thread and I’ll state 
>> things for end-to-end clarity.
>> 
>> It seems to me that we are talking about two possible scenarios: (1) the 
>> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
>> libswiftCore.dylib into two dylibs, one which includes some of the 
>> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits 
>> we will see with both scenarios, and see where the mismatch in our “talking 
>> past each other” is happening.
>> 
>> In both cases (A) and (B), with ABI stability the Standard Library has the 
>> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
>> no longer need to include libswiftCore.dylib in the app when running on an 
>> OS that shipped with the Standard Library.
>> 
>> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
>> (B):
>> 
>> 
>> (A) Status quo: Keep shipping everything in libswiftCore.dylib
>> 
>> - Applications running on an OS with the Standard Library would no longer 
>> have *any* of the currently libswift*.dylib’s embedded inside the 
>> application bundle because they would just use the one in the OS.
>> 
>> - One benefit of using libswift*.dylibs in the OS as opposed to those 
>> embedded inside the app bundle is that there is a non-neglible startup time 
>> improvement, as the code signing verification that happens when an app 
>> launches would be faster as it would not need to verify each of these dylibs 
>> that were previously embedded in the app.  We should consider this the new 
>> baseline for app startup time for an app running on an OS with an ABI stable 
>> Standard Library.
>> 
>> - We continue to support the deprecated APIs for some time, possibly 
>> indefinitely, even when better alternatives come around.
>> 
>> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the 
>> app bundle
>> 
>> In the second scenario, we split out the deprecated APIs into a separate 
>> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the 
>> following characteristics:
>> 
>> - Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
>> when running on an OS that had an ABI-stable Standard Library.
>> 
>> - Compared to scenario (A), the OS shipping the Standard Library would have 
>> a slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
>> deprecated APIs.  This would be a benefit in the code size for the OS, but 
>> not for the app itself.
>> 
>> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
>> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside 
>> their app bundle.  Compared to the new baseline I mentioned in (A), such 
>> apps would have a launch time regression once they started using any API in 
>> the libSwiftCoreDeprecated.dylib because code signing would need to verify 
>> the dylib, just like it does today with the libswiftCore.dylib that is 
>> embedded in every application.  They would also be slightly larger because 
>> the app bundle has the burden of hosting libswiftCoreDeprecated.dylib, 
>> instead of compared to scenario (A) where the implementations of the 
>> deprecated APIs are hosted by the libswiftCore.dylib that ships in the OS.
>> 
>> - Because of binary compatibility concerns, after Swift 5 we would *never* 
>> be able to “take out” any further APIs from libswiftCore.dylib and put them 
>> in libswiftCoreDeprecated.dylib.  This factorization can only happen once.
>> 
>> - There is some slight additional complexity added to the compiler and build 
>> system to support this spit of the Standard Library into multiple dylibs.  
>> It’s not a huge concern but it does exist and it is not free both in terms 
>> of implementing and maintaining.
>> 
>> - We continue to support the 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Jean-Daniel via swift-evolution]

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, else there is no point having it in the first place).


> Le 13 janv. 2018 à 01:43, Ted Kremenek via swift-evolution 
>  a écrit :
> 
> 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 thread and I’ll state things 
> for end-to-end clarity.
> 
> It seems to me that we are talking about two possible scenarios: (1) the 
> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
> libswiftCore.dylib into two dylibs, one which includes some of the 
> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits we 
> will see with both scenarios, and see where the mismatch in our “talking past 
> each other” is happening.
> 
> In both cases (A) and (B), with ABI stability the Standard Library has the 
> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
> no longer need to include libswiftCore.dylib in the app when running on an OS 
> that shipped with the Standard Library.
> 
> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
> (B):
> 
> 
> (A) Status quo: Keep shipping everything in libswiftCore.dylib
> 
> - Applications running on an OS with the Standard Library would no longer 
> have *any* of the currently libswift*.dylib’s embedded inside the application 
> bundle because they would just use the one in the OS.
> 
> - One benefit of using libswift*.dylibs in the OS as opposed to those 
> embedded inside the app bundle is that there is a non-neglible startup time 
> improvement, as the code signing verification that happens when an app 
> launches would be faster as it would not need to verify each of these dylibs 
> that were previously embedded in the app.  We should consider this the new 
> baseline for app startup time for an app running on an OS with an ABI stable 
> Standard Library.
> 
> - We continue to support the deprecated APIs for some time, possibly 
> indefinitely, even when better alternatives come around.
> 
> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the 
> app bundle
> 
> In the second scenario, we split out the deprecated APIs into a separate 
> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the 
> following characteristics:
> 
> - Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
> when running on an OS that had an ABI-stable Standard Library.
> 
> - Compared to scenario (A), the OS shipping the Standard Library would have a 
> slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
> deprecated APIs.  This would be a benefit in the code size for the OS, but 
> not for the app itself.
> 
> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside their 
> app bundle.  Compared to the new baseline I mentioned in (A), such apps would 
> have a launch time regression once they started using any API in the 
> libSwiftCoreDeprecated.dylib because code signing would need to verify the 
> dylib, just like it does today with the libswiftCore.dylib that is embedded 
> in every application.  They would also be slightly larger because the app 
> bundle has the burden of hosting libswiftCoreDeprecated.dylib, instead of 
> compared to scenario (A) where the implementations of the deprecated APIs are 
> hosted by the libswiftCore.dylib that ships in the OS.
> 
> - Because of binary compatibility concerns, after Swift 5 we would *never* be 
> able to “take out” any further APIs from libswiftCore.dylib and put them in 
> libswiftCoreDeprecated.dylib.  This factorization can only happen once.
> 
> - There is some slight additional complexity added to the compiler and build 
> system to support this spit of the Standard Library into multiple dylibs.  
> It’s not a huge concern but it does exist and it is not free both in terms of 
> implementing and maintaining.
> 
> - We continue to support the deprecated APIs for some time, possibly 
> indefinitely, even when better alternatives come around.  We *may* be able to 
> completely sunset these APIs by having a future version of the Swift compiler 
> simply refuse to build projects that use the deprecated (now obsoleted) APIs. 
>  At that point, these apps need to move to using the newer API alternatives, 
> or not upgrade to using a new Swift compiler.
> 
> 
> With these points in mind, both scenarios are (by construction) 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

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 bunch of 
> things I know *you* know, but others are on this thread and I’ll state things 
> for end-to-end clarity.

Sounds good.

> It seems to me that we are talking about two possible scenarios: (1) the 
> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
> libswiftCore.dylib into two dylibs, one which includes some of the 
> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits we 
> will see with both scenarios, and see where the mismatch in our “talking past 
> each other” is happening.

Right.

> In both cases (A) and (B), with ABI stability the Standard Library has the 
> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
> no longer need to include libswiftCore.dylib in the app when running on an OS 
> that shipped with the Standard Library.

Right.  Please keep in mind that both approaches also eliminate all the overlay 
dylibs for those apps, and both approaches put the vast majority of the stdlib 
code into the OS as well.  The ‘deprecated’ dylib is probably going to be 
comparatively small.

> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
> (B):
> 
> (A) Status quo: Keep shipping everything in libswiftCore.dylib
> 
> - Applications running on an OS with the Standard Library would no longer 
> have *any* of the currently libswift*.dylib’s embedded inside the application 
> bundle because they would just use the one in the OS.

Right.

> - One benefit of using libswift*.dylibs in the OS as opposed to those 
> embedded inside the app bundle is that there is a non-neglible startup time 
> improvement, as the code signing verification that happens when an app 
> launches would be faster as it would not need to verify each of these dylibs 
> that were previously embedded in the app.  We should consider this the new 
> baseline for app startup time for an app running on an OS with an ABI stable 
> Standard Library.

This happens with both models.  Refer back to the dyld optimization WWDC talk 
by Nick and Louis 2-3 years ago.  The big problem with Swift for startup time 
is that it adds half a dozen (or more) dylibs to your app bundle.  In the talk 
they make it clear that adding a single dylib is not a big deal, it is adding a 
bunch of dylibs that is the problem, particularly if they have 
interdependencies between them.

Neither approach presents this performance problem.

Further, if it were important to solve this startup time problem, it is 
straight-forward to solve it for apps that do want to deploy backward (which 
will be almost all of them in NMOS).  You’d do this by merging all the dylibs 
into a single one in the app bundle instead of leaving them to be independently 
resolved at load time.

> - We continue to support the deprecated APIs for some time, possibly 
> indefinitely, even when better alternatives come around.

Agreed.

> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the 
> app bundle
> 
> In the second scenario, we split out the deprecated APIs into a separate 
> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the 
> following characteristics:
> 
> - Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
> when running on an OS that had an ABI-stable Standard Library.
> 
> - Compared to scenario (A), the OS shipping the Standard Library would have a 
> slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
> deprecated APIs.  This would be a benefit in the code size for the OS, but 
> not for the app itself.

The code size is small so it doesn’t matter much either way, but this actually 
is an advantage for the average app.  Part of the point of this is that most 
apps don’t use this stuff, so they wouldn’t include the dylib at all.  There is 
no cost for them in either launch time or size.

To pick on Mirrors, the one example someone came up with is an API used by the 
swift on server community.  I haven’t heard of anyone using them in an iOS app 
(but of course I’m sure there is someone somewhere doing it :-)

> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside their 
> app bundle.  Compared to the new baseline I mentioned in (A), such apps would 
> have a launch time regression once they started using any API in the 
> libSwiftCoreDeprecated.dylib because code signing would need to verify the 
> dylib, just like it does today with the libswiftCore.dylib that is embedded 
> in every application.  They would also be slightly larger because the app 
> bundle has the burden of hosting 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

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, on the utility of having such a separate 
dylib for the purposes of sunsetting APIs.

Ted

> On Jan 12, 2018, at 6:02 PM, Xiaodi Wu  wrote:
> 
> 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 moment 
> it’s added seems unwise.
> 
> Against this consideration the benefit of enabling a more stable set and a 
> less stable set of APIs seems to outweigh the start-up time consideration. 
> Yes, the implication is that most Swift apps will have to incur an increased 
> runtime cost.
> On Fri, Jan 12, 2018 at 18:43 Ted Kremenek via swift-evolution 
> > 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 bunch of 
> things I know *you* know, but others are on this thread and I’ll state things 
> for end-to-end clarity.
> 
> It seems to me that we are talking about two possible scenarios: (1) the 
> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
> libswiftCore.dylib into two dylibs, one which includes some of the 
> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits we 
> will see with both scenarios, and see where the mismatch in our “talking past 
> each other” is happening.
> 
> In both cases (A) and (B), with ABI stability the Standard Library has the 
> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
> no longer need to include libswiftCore.dylib in the app when running on an OS 
> that shipped with the Standard Library.
> 
> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
> (B):
> 
> 
> (A) Status quo: Keep shipping everything in libswiftCore.dylib
> 
> - Applications running on an OS with the Standard Library would no longer 
> have *any* of the currently libswift*.dylib’s embedded inside the application 
> bundle because they would just use the one in the OS.
> 
> - One benefit of using libswift*.dylibs in the OS as opposed to those 
> embedded inside the app bundle is that there is a non-neglible startup time 
> improvement, as the code signing verification that happens when an app 
> launches would be faster as it would not need to verify each of these dylibs 
> that were previously embedded in the app.  We should consider this the new 
> baseline for app startup time for an app running on an OS with an ABI stable 
> Standard Library.
> 
> - We continue to support the deprecated APIs for some time, possibly 
> indefinitely, even when better alternatives come around.
> 
> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the 
> app bundle
> 
> In the second scenario, we split out the deprecated APIs into a separate 
> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the 
> following characteristics:
> 
> - Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
> when running on an OS that had an ABI-stable Standard Library.
> 
> - Compared to scenario (A), the OS shipping the Standard Library would have a 
> slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
> deprecated APIs.  This would be a benefit in the code size for the OS, but 
> not for the app itself.
> 
> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside their 
> app bundle.  Compared to the new baseline I mentioned in (A), such apps would 
> have a launch time regression once they started using any API in the 
> libSwiftCoreDeprecated.dylib because code signing would need to verify the 
> dylib, just like it does today with the libswiftCore.dylib that is embedded 
> in every application.  They would also be slightly larger because the app 
> bundle has the burden of hosting libswiftCoreDeprecated.dylib, instead of 
> compared to scenario (A) where the implementations of the deprecated APIs are 
> hosted by the libswiftCore.dylib that ships in the OS.
> 
> - Because of binary compatibility concerns, after Swift 5 we would *never* be 
> able to “take out” any further APIs from libswiftCore.dylib and put them in 
> libswiftCoreDeprecated.dylib.  This factorization can only happen once.
> 
> - There is some slight additional complexity 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Xiaodi Wu via swift-evolution]

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
moment it’s added seems unwise.

Against this consideration the benefit of enabling a more stable set and a
less stable set of APIs seems to outweigh the start-up time consideration.
Yes, the implication is that most Swift apps will have to incur an
increased runtime cost.
On Fri, Jan 12, 2018 at 18:43 Ted Kremenek via swift-evolution <
swift-evolution@swift.org> 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 bunch of things I know *you* know, but others are on this
> thread and I’ll state things for end-to-end clarity.
>
> It seems to me that we are talking about two possible scenarios: (1) the
> status quo of keeping everything in libswiftCore.dylib or (2) splitting
> libswiftCore.dylib into two dylibs, one which includes some of the
> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits
> we will see with both scenarios, and see where the mismatch in our “talking
> past each other” is happening.
>
> In both cases (A) and (B), with ABI stability the Standard Library has the
> option to ship in the OS.  Thus applications using Swift on (say) iOS would
> no longer need to include libswiftCore.dylib in the app when running on an
> OS that shipped with the Standard Library.
>
> With that in mind, here are the tradeoffs as I see between scenarios (A)
> and (B):
>
>
> (A) Status quo: Keep shipping everything in libswiftCore.dylib
>
> - Applications running on an OS with the Standard Library would no longer
> have *any* of the currently libswift*.dylib’s embedded inside the
> application bundle because they would just use the one in the OS.
>
> - One benefit of using libswift*.dylibs in the OS as opposed to those
> embedded inside the app bundle is that there is a non-neglible startup time
> improvement, as the code signing verification that happens when an app
> launches would be faster as it would not need to verify each of these
> dylibs that were previously embedded in the app.  We should consider this
> the new baseline for app startup time for an app running on an OS with an
> ABI stable Standard Library.
>
> - We continue to support the deprecated APIs for some time, possibly
> indefinitely, even when better alternatives come around.
>
> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in
> the app bundle
>
> In the second scenario, we split out the deprecated APIs into a separate
> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the
> following characteristics:
>
> - Like scenario (A), app bundles would not need to embed
> libswiftCore.dylib when running on an OS that had an ABI-stable Standard
> Library.
>
> - Compared to scenario (A), the OS shipping the Standard Library would
> have a slightly smaller libswiftCore.dylib that didn’t carry the bits for
> the deprecated APIs.  This would be a benefit in the code size for the OS,
> but not for the app itself.
>
> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib
> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside
> their app bundle.  Compared to the new baseline I mentioned in (A), such
> apps would have a launch time regression once they started using any API in
> the libSwiftCoreDeprecated.dylib because code signing would need to verify
> the dylib, just like it does today with the libswiftCore.dylib that is
> embedded in every application.  They would also be slightly larger because
> the app bundle has the burden of hosting libswiftCoreDeprecated.dylib,
> instead of compared to scenario (A) where the implementations of the
> deprecated APIs are hosted by the libswiftCore.dylib that ships in the OS.
>
> - Because of binary compatibility concerns, after Swift 5 we would *never*
> be able to “take out” any further APIs from libswiftCore.dylib and put them
> in libswiftCoreDeprecated.dylib.  This factorization can only happen once.
>
> - There is some slight additional complexity added to the compiler and
> build system to support this spit of the Standard Library into multiple
> dylibs.  It’s not a huge concern but it does exist and it is not free both
> in terms of implementing and maintaining.
>
> - We continue to support the deprecated APIs for some time, possibly
> indefinitely, even when better alternatives come around.  We *may* be able
> to completely sunset these APIs by having a future version of the Swift
> compiler simply refuse to build projects that use the deprecated (now
> obsoleted) APIs.  At that point, these apps need to move to using 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

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 thread and I’ll state things 
for end-to-end clarity.

It seems to me that we are talking about two possible scenarios: (1) the status 
quo of keeping everything in libswiftCore.dylib or (2) splitting 
libswiftCore.dylib into two dylibs, one which includes some of the “deprecated” 
APIs.  I’ll enumerate what I think are the tradeoffs/benefits we will see with 
both scenarios, and see where the mismatch in our “talking past each other” is 
happening.

In both cases (A) and (B), with ABI stability the Standard Library has the 
option to ship in the OS.  Thus applications using Swift on (say) iOS would no 
longer need to include libswiftCore.dylib in the app when running on an OS that 
shipped with the Standard Library.

With that in mind, here are the tradeoffs as I see between scenarios (A) and 
(B):


(A) Status quo: Keep shipping everything in libswiftCore.dylib

- Applications running on an OS with the Standard Library would no longer have 
*any* of the currently libswift*.dylib’s embedded inside the application bundle 
because they would just use the one in the OS.

- One benefit of using libswift*.dylibs in the OS as opposed to those embedded 
inside the app bundle is that there is a non-neglible startup time improvement, 
as the code signing verification that happens when an app launches would be 
faster as it would not need to verify each of these dylibs that were previously 
embedded in the app.  We should consider this the new baseline for app startup 
time for an app running on an OS with an ABI stable Standard Library.

- We continue to support the deprecated APIs for some time, possibly 
indefinitely, even when better alternatives come around.

(B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the app 
bundle

In the second scenario, we split out the deprecated APIs into a separate dylib, 
say libswiftCoreDeprecated.dylib.  That solution would have the following 
characteristics:

- Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
when running on an OS that had an ABI-stable Standard Library.

- Compared to scenario (A), the OS shipping the Standard Library would have a 
slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
deprecated APIs.  This would be a benefit in the code size for the OS, but not 
for the app itself.

- Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
(e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside their 
app bundle.  Compared to the new baseline I mentioned in (A), such apps would 
have a launch time regression once they started using any API in the 
libSwiftCoreDeprecated.dylib because code signing would need to verify the 
dylib, just like it does today with the libswiftCore.dylib that is embedded in 
every application.  They would also be slightly larger because the app bundle 
has the burden of hosting libswiftCoreDeprecated.dylib, instead of compared to 
scenario (A) where the implementations of the deprecated APIs are hosted by the 
libswiftCore.dylib that ships in the OS.

- Because of binary compatibility concerns, after Swift 5 we would *never* be 
able to “take out” any further APIs from libswiftCore.dylib and put them in 
libswiftCoreDeprecated.dylib.  This factorization can only happen once.

- There is some slight additional complexity added to the compiler and build 
system to support this spit of the Standard Library into multiple dylibs.  It’s 
not a huge concern but it does exist and it is not free both in terms of 
implementing and maintaining.

- We continue to support the deprecated APIs for some time, possibly 
indefinitely, even when better alternatives come around.  We *may* be able to 
completely sunset these APIs by having a future version of the Swift compiler 
simply refuse to build projects that use the deprecated (now obsoleted) APIs.  
At that point, these apps need to move to using the newer API alternatives, or 
not upgrade to using a new Swift compiler.


With these points in mind, both scenarios are (by construction) very similar.  
Scenario (B) potentially provides a bit more flexibility in outright sunsetting 
deprecated APIs down the road — but only the APIs we deem today should be on 
that path. In the future when we decide to deprecate APIs in the Standard 
Library we will need to follow the same kind of deprecation-and-obsoletion path 
as other binary frameworks in macOS/iOS, which may mean keeping API 
implementations around for a very long time just for the purpose of binary 
compatibility.

If you agree with me up to this point, to me this boils down to a tradeoff of 
some slightly increased opportunity to sunset some APIs in the 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Hooman Mehr via swift-evolution]

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 
> module doesn’t go into the OS.  Only people that use it pay to cost.

As I said, I totally agree.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

> On Jan 11, 2018, at 12:22 AM, Ted Kremenek  wrote:
> 
> 
> 
>> 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).
>> 
>> It directly impacts code size for applications of swift that use the 
>> standard library as a standard library, e.g. a raspberry pi dev situation.
> 
> I’m not arguing that we should have profligate bloat in the Standard library, 
> but I feel that if we are seriously talking about scenarios where we want a 
> super-svelt Standard library for particular use-cases where code size and 
> other factors are a major concern, 

No, that is not what I’m talking about at all.  Mirrors are completely wrong.  
There is nothing saving them, they must be replaced.  It is now clear that 
isn’t going to happen this year (which is fine) but that doesn’t mean that they 
should be a first class part of the Swift experience “forever”.

We have an opportunity here to fix this.

-Chris


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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

> 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 :-)
> 
> Hi Chris,
> 
> Even if we split the APIs into two sets, with an “ABI unstable” subset, we 
> are still going to “carry round these ’suboptimal APIs’” because clients are 
> using them today and those APIs — without an active plan to remove them — 
> *are* a part of the Standard Library.  We’ve past the point in Swift where we 
> can just rip them out (you said so yourself in a follow up email).

Who is “we” and how do you define carry?

I think you’re saying that they will remain part of the swift project (in the 
“SwiftDeprecated” module) for effectively ever.  If so, I agree, and that’s the 
point.  The point is that the code can continue to exist and service the few 
people who need it (and will become even fewer over the years) without causing 
*harm* to the Swift ecosystem over the near or long term.  That’s the feature.

> It feels to me that the main advantage of the overlay is a solution to remove 
> out pieces of the Standard Library that will be used in practice less, and 
> thus clients don’t “pay the cost” when they don’t use them.

Yes, exactly.

> But I think we should be honest about what that “cost” actually is, as these 
> APIs aren’t going away right now.  These suboptimal APIs will stay around at 
> least until better ones are created, and even then some existing clients will 
> want to rely on the existing suboptimal APIs anyway even if others want to 
> take advantage of newer, better APIs and idioms.

I’m not sure what you mean.  I’m talking about two things specifically:

1) APIs that are already deprecated and have replacements.  The deprecated 
version goes in this library, avoid carrying them around forever.

2) APIs that are used by extremely narrow audiences, which were added without 
much consideration and that have not been redesigned since Swift 1.  Mirror’s 
are an example of this.  I’m arguing that these should be moved to this 
SwiftDeprecated module - but not actually deprecated until a replacement exists.

I don’t see how this is bad for anyone, and I think this provides a significant 
process improvement compared to your current approach, which forces you to lock 
down APIs now without careful consideration just because they are not 
“important enough”.

> The main cost I see here that we save by having an “overlay for the Standard 
> library" is code size.  

I don’t understand this point.

> On macOS/iOS it is true that applications embed a copy of the Standard 
> Library within them and thus pay a real cost in the Standard Library’s 
> actually payload size in their own app.  However, the only reason that is 
> necessary today is because we don’t have ABI stability.  With ABI stability, 
> other options for shipping the Standard Library — such as shipping it in the 
> OS — become possible, and thus the burden of shouldering that “cost” of code 
> size shifts around.  Then the tradeoffs of having an overlay for the Standard 
> Library are different.  In a world with ABI stability, is it better to have a 
> Standard Library "overlay" that only some clients use, and embed within their 
> application bundle, than just eat that cost in the Standard Library to be 
> shared by potentially multiple clients installed on a system?  I think it 
> really comes down to the numbers.  In that case, are we really just talking 
> about Mirrors?  I haven’t run the numbers here, but my intuition tells me we 
> are talking about a relatively small code size impact overall.

This comment doesn’t make a lot of sense to me, perhaps we’re talking across 
each other.  The point of the design that I’m advocating for is that all apps 
(that deploy to iOS-next or later) get a immediate improvement from abi 
stability: the vast majority of the standard library is not put into their app 
bundle.  Further, the vastly most common apps - those that are not using 
mirrors or deprecated APIs, also do not include the SwiftDeprecated module.  

Only the tiny minority of apps that do use these APIs would have a copy of 
SwiftDeprecated in their app dylib, but they have a path to fix that, and they 
would still see a huge improvement from the bulk of the standard library being 
out of their app bundle.

> 
> There’s also other potential performance implications from doing this split.  

This doesn’t make sense to me.  We’re not talking about taking comonly used 
apis here.  Mirrors are not performance sensitive at all, and neither are 
deprecated wrappers of renamed APIs.

> Being able to have the Standard Library be in the OS has potential major 
> implications on the startup time of Swift applications.

It is great for app developers to have an incentive to stop using deprecated 
APIs! 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

> 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 around these 
> “suboptimal” APIs forever, particularly given how marginal they are (as in, 
> not widely used).  I’m sure that there are other examples beyond these that 
> are similarly unfortunate.
> 
> Given that, I have a meta question for you: have you considered an approach 
> where you take the Swift standard library and split it into two conceptual 
> pieces:
> 
> 1) The "ABI stable” subset of the library that gets burned into the OS.
> 2) The “ABI unstable” subset, which gets statically linked into apps, just 
> like the Swift 4 library used to?
> 
> Given that “import Swift” is implicit anyway, you could just have the 
> compiler implicitly import *both* of these modules.  
> 
> 
> The point of doing this is that it gives you a very general and low friction 
> way to handle compatibility gunk.  In addition to putting obscure stuff like 
> Mirror and “DictionaryLiteral” into this (without breaking source code!) you 
> now get the ability to put the various deprecated forwarding functions in 
> this module as well, avoiding them becoming part of the ABI.
> 
> 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 :-)

Hi Chris,

Even if we split the APIs into two sets, with an “ABI unstable” subset, we are 
still going to “carry round these ’suboptimal APIs’” because clients are using 
them today and those APIs — without an active plan to remove them — *are* a 
part of the Standard Library.  We’ve past the point in Swift where we can just 
rip them out (you said so yourself in a follow up email).

It feels to me that the main advantage of the overlay is a solution to remove 
out pieces of the Standard Library that will be used in practice less, and thus 
clients don’t “pay the cost” when they don’t use them.  But I think we should 
be honest about what that “cost” actually is, as these APIs aren’t going away 
right now.  These suboptimal APIs will stay around at least until better ones 
are created, and even then some existing clients will want to rely on the 
existing suboptimal APIs anyway even if others want to take advantage of newer, 
better APIs and idioms.

The main cost I see here that we save by having an “overlay for the Standard 
library" is code size.  On macOS/iOS it is true that applications embed a copy 
of the Standard Library within them and thus pay a real cost in the Standard 
Library’s actually payload size in their own app.  However, the only reason 
that is necessary today is because we don’t have ABI stability.  With ABI 
stability, other options for shipping the Standard Library — such as shipping 
it in the OS — become possible, and thus the burden of shouldering that “cost” 
of code size shifts around.  Then the tradeoffs of having an overlay for the 
Standard Library are different.  In a world with ABI stability, is it better to 
have a Standard Library "overlay" that only some clients use, and embed within 
their application bundle, than just eat that cost in the Standard Library to be 
shared by potentially multiple clients installed on a system?  I think it 
really comes down to the numbers.  In that case, are we really just talking 
about Mirrors?  I haven’t run the numbers here, but my intuition tells me we 
are talking about a relatively small code size impact overall.

There’s also other potential performance implications from doing this split.  
Being able to have the Standard Library be in the OS has potential major 
implications on the startup time of Swift applications.  Right now, with the 
Swift overlay libraries being part of the application bundle, on macOS/iOS 
there is a real startup time impact of having these libraries shipped in 
applications this way.  Obviously reducing these down to one overlay — and 
overlay that hypothetically wouldn’t be used often — would be a major 
improvement over what we have today.  But this would also introduce a 
performance cliff for some clients that wanted to use the parts of the Standard 
Library that were deemed “ABI unstable”.  If an app starts using one of the 
APIs in this part of the Standard Library — and possibly through an 
intermediary such as a Swift package — then the app silently starts using this 
overlay and thus gets the startup time hit and other costs of using it.  For 
some clients that will seem like an obscure performance cliff.  In all 
fairness, “cliff” might be hyperbole here, but my point is that the tradeoffs 
of costs here are not linear and make the performance programming model of 
using Swift a 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

> 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).
> 
> It directly impacts code size for applications of swift that use the standard 
> library as a standard library, e.g. a raspberry pi dev situation.

I’m not arguing that we should have profligate bloat in the Standard library, 
but I feel that if we are seriously talking about scenarios where we want a 
super-svelt Standard library for particular use-cases where code size and other 
factors are a major concern, then I think that discussion goes well beyond just 
cutting out APIs like Mirrors.  Depending on the domain, other parts of the 
Standard library seem like prime candidates to jettison as they may not carry 
their weight *in those contexts*, even if those APIs are well-used in others.

In other words, we have various knobs we can pull here in this design space, 
and the needs of Swift in different domains may be slightly different to be 
worth exploring different options where appropriate.  That’s not to say that 
the ideas you are putting forth don’t have merit, but I think there is a danger 
with lumping all of this up with the discussion about ABI stability in Swift 5. 
 More generally, I do think the idea of possibly carving up the Standard 
Library into layers is a possible useful design idiom when considering Swift 
being used in different contexts with different requirements/needs/constraints, 
but an exploration of that idea doesn’t have to be tied to ABI stability.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

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 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 of this piece and keep 
> all versions on the SO. (I think the Microsoft did something similar to this)
> 
> On Linux the package manager probably will handle this very well like any 
> other library.
> 
> Even 100 versions in the same SO will not consume enough space to bother 
> anyone.
> 
> 
> Em qua, 10 de jan de 2018 às 17:04, Hooman Mehr via swift-evolution 
> > escreveu:
> 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 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 them to something better (and I’m not aware of 
> >> one pending), the plan is they are what they are, at least the public API 
> >> of Swift.Mirror. I would guess this whole area is a candidate to be 
> >> overhauled significantly at some point in the post-Swift 5 future with 
> >> some more fully-fledged reflection system, but there is little chance of 
> >> this happening before ABI stability, and interim tinkering doesn’t seem 
> >> worthwhile to me.
> >
> > 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 these 
> > “suboptimal” APIs forever, particularly given how marginal they are (as in, 
> > not widely used).  I’m sure that there are other examples beyond these that 
> > are similarly unfortunate.
> >
> > Given that, I have a meta question for you: have you considered an approach 
> > where you take the Swift standard library and split it into two conceptual 
> > pieces:
> >
> > 1) The "ABI stable” subset of the library that gets burned into the OS.
> > 2) The “ABI unstable” subset, which gets statically linked into apps, just 
> > like the Swift 4 library used to?
> >
> > Given that “import Swift” is implicit anyway, you could just have the 
> > compiler implicitly import *both* of these modules.
> >
> >
> > The point of doing this is that it gives you a very general and low 
> > friction way to handle compatibility gunk.  In addition to putting obscure 
> > stuff like Mirror and “DictionaryLiteral” into this (without breaking 
> > source code!) you now get the ability to put the various deprecated 
> > forwarding functions in this module as well, avoiding them becoming part of 
> > the ABI.
> >
> > 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 :-)
> >
> >>> +1 for renaming it to something that isn’t super confusing, but +100 for 
> >>> removing it outright.
> >>>
> >>> Rationale: if we didn’t have this functionality in the stdlib today, we 
> >>> would not consider adding it.  It doesn’t meet the bar we’ve set for what 
> >>> is in the standard library.  It only exists there by historical accident. 
> >>>  The Mirror API was not carefully considered.
> >>>
> >>
> >> Personally, I feel like this argument for removal as past its use-by date. 
> >> It was a good reason for Swift 3, tenuous for 4 and should be ruled out 
> >> for 5, since the source stability bar has been raised since. Like I said, 
> >> IMO the criteria should now be “active harm”. I also don’t think searches 
> >> of GitHub etc are sufficient justification, except when combined with the 
> >> active-harm argument. I also don’t think the origin story of the type – 
> >> whether accidental or intentional – is relevant to the decision of what to 
> >> do with it now. It exists and people can legitimately use it for their own 
> >> purposes independent of mirrors.
> >
> > I’m generally in agreement with you, but in 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Wallacy via swift-evolution]

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 of this piece and keep
all versions on the SO. (I think the Microsoft did something similar to
this)

On Linux the package manager probably will handle this very well like any
other library.

Even 100 versions in the same SO will not consume enough space to bother
anyone.


Em qua, 10 de jan de 2018 às 17:04, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> escreveu:

> 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 <
> swift-evolution@swift.org> wrote:
> >
> > 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 them to something better (and I’m not aware
> of one pending), the plan is they are what they are, at least the public
> API of Swift.Mirror. I would guess this whole area is a candidate to be
> overhauled significantly at some point in the post-Swift 5 future with some
> more fully-fledged reflection system, but there is little chance of this
> happening before ABI stability, and interim tinkering doesn’t seem
> worthwhile to me.
> >
> > 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
> these “suboptimal” APIs forever, particularly given how marginal they are
> (as in, not widely used).  I’m sure that there are other examples beyond
> these that are similarly unfortunate.
> >
> > Given that, I have a meta question for you: have you considered an
> approach where you take the Swift standard library and split it into two
> conceptual pieces:
> >
> > 1) The "ABI stable” subset of the library that gets burned into the OS.
> > 2) The “ABI unstable” subset, which gets statically linked into apps,
> just like the Swift 4 library used to?
> >
> > Given that “import Swift” is implicit anyway, you could just have the
> compiler implicitly import *both* of these modules.
> >
> >
> > The point of doing this is that it gives you a very general and low
> friction way to handle compatibility gunk.  In addition to putting obscure
> stuff like Mirror and “DictionaryLiteral” into this (without breaking
> source code!) you now get the ability to put the various deprecated
> forwarding functions in this module as well, avoiding them becoming part of
> the ABI.
> >
> > 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 :-)
> >
> >>> +1 for renaming it to something that isn’t super confusing, but +100
> for removing it outright.
> >>>
> >>> Rationale: if we didn’t have this functionality in the stdlib today,
> we would not consider adding it.  It doesn’t meet the bar we’ve set for
> what is in the standard library.  It only exists there by historical
> accident.  The Mirror API was not carefully considered.
> >>>
> >>
> >> Personally, I feel like this argument for removal as past its use-by
> date. It was a good reason for Swift 3, tenuous for 4 and should be ruled
> out for 5, since the source stability bar has been raised since. Like I
> said, IMO the criteria should now be “active harm”. I also don’t think
> searches of GitHub etc are sufficient justification, except when combined
> with the active-harm argument. I also don’t think the origin story of the
> type – whether accidental or intentional – is relevant to the decision of
> what to do with it now. It exists and people can legitimately use it for
> their own purposes independent of mirrors.
> >
> > I’m generally in agreement with you, but in this specific case, I
> seriously doubt people are using this.  All rules are malleable in the
> right circumstances.
> >
> > More importantly though, if we had a meta design that allowed to
> gracefully phase this sort of thing out (without it becoming part of ABI
> under any name) there becomes very little cost to leaving it around in the
> “abi unstable” library for…. ever if need be.  Given that, I would have
> much less objection to keeping it around.
> >
> > -Chris
> >
> > ___
> > swift-evolution mailing list
> > 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Hooman Mehr via swift-evolution]

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 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 them to something better (and I’m not aware of 
>> one pending), the plan is they are what they are, at least the public API of 
>> Swift.Mirror. I would guess this whole area is a candidate to be overhauled 
>> significantly at some point in the post-Swift 5 future with some more 
>> fully-fledged reflection system, but there is little chance of this 
>> happening before ABI stability, and interim tinkering doesn’t seem 
>> worthwhile to me.
> 
> 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 these 
> “suboptimal” APIs forever, particularly given how marginal they are (as in, 
> not widely used).  I’m sure that there are other examples beyond these that 
> are similarly unfortunate.
> 
> Given that, I have a meta question for you: have you considered an approach 
> where you take the Swift standard library and split it into two conceptual 
> pieces:
> 
> 1) The "ABI stable” subset of the library that gets burned into the OS.
> 2) The “ABI unstable” subset, which gets statically linked into apps, just 
> like the Swift 4 library used to?
> 
> Given that “import Swift” is implicit anyway, you could just have the 
> compiler implicitly import *both* of these modules.  
> 
> 
> The point of doing this is that it gives you a very general and low friction 
> way to handle compatibility gunk.  In addition to putting obscure stuff like 
> Mirror and “DictionaryLiteral” into this (without breaking source code!) you 
> now get the ability to put the various deprecated forwarding functions in 
> this module as well, avoiding them becoming part of the ABI.
> 
> 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 :-)
> 
>>> +1 for renaming it to something that isn’t super confusing, but +100 for 
>>> removing it outright.
>>> 
>>> Rationale: if we didn’t have this functionality in the stdlib today, we 
>>> would not consider adding it.  It doesn’t meet the bar we’ve set for what 
>>> is in the standard library.  It only exists there by historical accident.  
>>> The Mirror API was not carefully considered.
>>> 
>> 
>> Personally, I feel like this argument for removal as past its use-by date. 
>> It was a good reason for Swift 3, tenuous for 4 and should be ruled out for 
>> 5, since the source stability bar has been raised since. Like I said, IMO 
>> the criteria should now be “active harm”. I also don’t think searches of 
>> GitHub etc are sufficient justification, except when combined with the 
>> active-harm argument. I also don’t think the origin story of the type – 
>> whether accidental or intentional – is relevant to the decision of what to 
>> do with it now. It exists and people can legitimately use it for their own 
>> purposes independent of mirrors.
> 
> I’m generally in agreement with you, but in this specific case, I seriously 
> doubt people are using this.  All rules are malleable in the right 
> circumstances.
> 
> More importantly though, if we had a meta design that allowed to gracefully 
> phase this sort of thing out (without it becoming part of ABI under any name) 
> there becomes very little cost to leaving it around in the “abi unstable” 
> library for…. ever if need be.  Given that, I would have much less objection 
> to keeping it around.
> 
> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

> 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.  That said, it would 
>> be really unfortunate to carry
>> around these “suboptimal” APIs forever, particularly given how marginal they 
>> are (as in, not widely used).
> 
> It's true that they are not widely used, but they are in use.  For
> example IBM's SQL abstraction library called "Kuery" depends on
> Mirror.
> 
> https://github.com/IBM-Swift/Swift-Kuery/blob/1d05ad6435cf7fa5feebba663bd3f765c72634e1/Sources/SwiftKuery/Table.swift#L42
>  
> 

Right.  That’s exactly the reason we don’t want to remove them outright (that 
would be a major source breakage).  Moving them to a separate module solves 
this concern and allows a better implementation to come in and be standardized 
later.

-Chris

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ian Partridge via swift-evolution]

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 these “suboptimal” APIs forever, particularly given how marginal they 
> are (as in, not widely used).

It's true that they are not widely used, but they are in use.  For
example IBM's SQL abstraction library called "Kuery" depends on
Mirror.

https://github.com/IBM-Swift/Swift-Kuery/blob/1d05ad6435cf7fa5feebba663bd3f765c72634e1/Sources/SwiftKuery/Table.swift#L42

-- 
Ian Partridge
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

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 them to something better (and I’m not aware of 
> one pending), the plan is they are what they are, at least the public API of 
> Swift.Mirror. I would guess this whole area is a candidate to be overhauled 
> significantly at some point in the post-Swift 5 future with some more 
> fully-fledged reflection system, but there is little chance of this happening 
> before ABI stability, and interim tinkering doesn’t seem worthwhile to me.

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 these 
“suboptimal” APIs forever, particularly given how marginal they are (as in, not 
widely used).  I’m sure that there are other examples beyond these that are 
similarly unfortunate.

Given that, I have a meta question for you: have you considered an approach 
where you take the Swift standard library and split it into two conceptual 
pieces:

1) The "ABI stable” subset of the library that gets burned into the OS.
2) The “ABI unstable” subset, which gets statically linked into apps, just like 
the Swift 4 library used to?

Given that “import Swift” is implicit anyway, you could just have the compiler 
implicitly import *both* of these modules.  


The point of doing this is that it gives you a very general and low friction 
way to handle compatibility gunk.  In addition to putting obscure stuff like 
Mirror and “DictionaryLiteral” into this (without breaking source code!) you 
now get the ability to put the various deprecated forwarding functions in this 
module as well, avoiding them becoming part of the ABI.

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 :-)

>> +1 for renaming it to something that isn’t super confusing, but +100 for 
>> removing it outright.
>> 
>> Rationale: if we didn’t have this functionality in the stdlib today, we 
>> would not consider adding it.  It doesn’t meet the bar we’ve set for what is 
>> in the standard library.  It only exists there by historical accident.  The 
>> Mirror API was not carefully considered.
>> 
> 
> Personally, I feel like this argument for removal as past its use-by date. It 
> was a good reason for Swift 3, tenuous for 4 and should be ruled out for 5, 
> since the source stability bar has been raised since. Like I said, IMO the 
> criteria should now be “active harm”. I also don’t think searches of GitHub 
> etc are sufficient justification, except when combined with the active-harm 
> argument. I also don’t think the origin story of the type – whether 
> accidental or intentional – is relevant to the decision of what to do with it 
> now. It exists and people can legitimately use it for their own purposes 
> independent of mirrors.

I’m generally in agreement with you, but in this specific case, I seriously 
doubt people are using this.  All rules are malleable in the right 
circumstances.

More importantly though, if we had a meta design that allowed to gracefully 
phase this sort of thing out (without it becoming part of ABI under any name) 
there becomes very little cost to leaving it around in the “abi unstable” 
library for…. ever if need be.  Given that, I would have much less objection to 
keeping it around.

-Chris

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Brent Royal-Gordon via swift-evolution]

> 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`.


Sorry, I meant to provide an alternative but forgot.

If we can't do this, I think we should call it something like `PairArray` or 
`KeyValueArray` and augment its API to bring it closer to parity with `Array`. 
This type really does have the same semantics as `Array`—integer-indexed, 
order-preserving, random-access, etc.—and I think we should leverage that fact 
to make its behavior clear.

`PairArray` sort of vaguely suggests that we should have a `public typealias 
Pair = (key: K, value: V)` in the standard library. I think that's 
actually a good idea, because we can use it to make sure that we use tuple 
element labels consistently across various APIs.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Charles Constant via swift-evolution]

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 literals, not DictionaryLiteral. We
> are talking about the (clearly confusingly named!) DictionaryLiteral type,
> which is a type you can create from a dictionary literal. (See docs here:
> https://developer.apple.com/documentation/swift/dictionaryliteral)
>
> There’s no suggestion of getting rid of the ExpressibleByDictionaryLiteral
> capability.
>
> “Ceci n’est pas une literal”
>  - Magritte
>
> On Jan 9, 2018, at 8:26 PM, Charles Constant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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, the "
> ExpressibleByDictionaryLiteral" lets me specify a "params" template
> tersely. I only found out how to use the -Literal initializers last year. I
> love them.
>
> struct DrumNote: ParameterSet {
> let rawValue: UInt
>
> static let params: [ParamType] = [ ["velocity":0...255], "flam", "roll",
> "reverse" ]
>
> static let
> velocity = param(0),
> flam = param(1),
> roll = param(2),
> reverse = param(3),
>
> // ...
>
> }
>
> enum ParamType: ExpressibleByStringLiteral, ExpressibleByDictionaryLiteral
> {
> public init( dictionaryLiteral elements: (String,Any)... ) {
> if let pair = elements.first as? (String,ClosedRange) {
> self = .doub(pair.0,pair.1) }
> else if let pair = elements.first as? 
> (String,CountableClosedRange)
> { self = .int(pair.0, pair.1.lowerBound ... pair.1.upperBound ) }
> else { fatalError("Can only init from Double...Double or Int...Int") }
> }
>
> // ...
> }
>
>
> On Tue, Jan 9, 2018 at 6:10 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> 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 varieties) aren't used
>>> more often is because Swift programmers don't realize they are available
>>> and easy to implement.
>>>
>>
>> Could you provide an example of how you used DictionaryLiteral?
>>
>> Nevin
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
On Tue, Jan 9, 2018 at 8:26 PM, Charles Constant via swift-evolution <
swift-evolution@swift.org> wrote:

> 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, the "
> ExpressibleByDictionaryLiteral" lets me specify a "params" template
> tersely. I only found out how to use the -Literal initializers last year. I
> love them.
>
> struct DrumNote: ParameterSet {
> let rawValue: UInt
>
> static let params: [ParamType] = [ ["velocity":0...255], "flam", "roll",
> "reverse" ]
>
> static let
> velocity = param(0),
> flam = param(1),
> roll = param(2),
> reverse = param(3),
>
> // ...
>
> }
>
> enum ParamType: ExpressibleByStringLiteral, ExpressibleByDictionaryLiteral
> {
> public init( dictionaryLiteral elements: (String,Any)... ) {
> if let pair = elements.first as? (String,ClosedRange) {
> self = .doub(pair.0,pair.1) }
> else if let pair = elements.first as? 
> (String,CountableClosedRange)
> { self = .int(pair.0, pair.1.lowerBound ... pair.1.upperBound ) }
> else { fatalError("Can only init from Double...Double or Int...Int") }
> }
>
> // ...
> }
>
>
> On Tue, Jan 9, 2018 at 6:10 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> 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 varieties) aren't used
>>> more often is because Swift programmers don't realize they are available
>>> and easy to implement.
>>>
>>
>> Could you provide an example of how you used DictionaryLiteral?
>>
>> Nevin
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Brent Royal-Gordon via swift-evolution]

> 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 already familiar. Also 
> “association” and “associative” are confusingly similar, which brings back 
> the is-this-a-dictionary problem.
> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
> different context in Cocoa.
> - `PairCollection`: “Pair” is kinda nondescript.
> - Do nothing. It’s not so bad.


I think the best solution by far would be to provide an `extension Array: 
ExpressibleByDictionaryLiteral where Element == (Key, Value)` conformance. 
Besides the name, `DictionaryLiteral` basically has the same semantics as 
`Array`, but an impoverished subset of its functionality; using `Array` would 
reduce the standard library's surface area *and* improve the usability of code 
which currently uses `DictionaryLiteral`.

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`. It seems like enough of a win, 
in both surface area and functionality, to justify a little compiler weirdness. 
(And we don't need to test for `_AnyTupleOfTwo` conformance at runtime, so I 
don't think it's a problem if `is` and `as?` don't work.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Charles Constant via swift-evolution]

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, the
"ExpressibleByDictionaryLiteral" lets me specify a "params" template
tersely. I only found out how to use the -Literal initializers last year. I
love them.

struct DrumNote: ParameterSet {
let rawValue: UInt

static let params: [ParamType] = [ ["velocity":0...255], "flam", "roll",
"reverse" ]

static let
velocity = param(0),
flam = param(1),
roll = param(2),
reverse = param(3),

// ...

}

enum ParamType: ExpressibleByStringLiteral, ExpressibleByDictionaryLiteral {
public init( dictionaryLiteral elements: (String,Any)... ) {
if let pair = elements.first as? (String,ClosedRange) {
self = .doub(pair.0,pair.1) }
else if let pair = elements.first as?
(String,CountableClosedRange) { self = .int(pair.0,
pair.1.lowerBound ... pair.1.upperBound ) }
else { fatalError("Can only init from Double...Double or Int...Int") }
}

// ...
}


On Tue, Jan 9, 2018 at 6:10 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> 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 varieties) aren't used
>> more often is because Swift programmers don't realize they are available
>> and easy to implement.
>>
>
> Could you provide an example of how you used DictionaryLiteral?
>
> Nevin
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nevin Brackett-Rozinsky via swift-evolution]

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 this type accepts duplicate “keys” and does not provide key-based
> lookup, the first thing that deserves a rename is “Key” generic parameter.
> I recommend naming it “Label”.
>
> This type represents how a dictionary literal *looks*, not what it *means*.
> When we consider the look of it, a dictionary literal is an array literal
> where each element is labeled.
>
> I can’t think of a really good name, but we may be able to find a more
> accurate and less confusing name.
>
> Some of the more accurate names are:
>
> LabeledElementCollection
> LabeledValueCollection
> LabeledValueList
> LabeledList
>
> By the way, why this type does not conform to any of the collection
> protocols while duplicating a lot of collection APIs?
>


+1 to “LabeledList”

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Hooman Mehr via swift-evolution]

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 rename is “Key” generic parameter. I recommend 
naming it “Label”.  

This type represents how a dictionary literal looks, not what it means. When we 
consider the look of it, a dictionary literal is an array literal where each 
element is labeled. 

I can’t think of a really good name, but we may be able to find a more accurate 
and less confusing name.

Some of the more accurate names are:

LabeledElementCollection
LabeledValueCollection
LabeledValueList
LabeledList

By the way, why this type does not conform to any of the collection protocols 
while duplicating a lot of collection APIs?

> 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 
> key-based lookup of values) nor a Literal. 
> 
> Instead, it’s just an immutable collection of key-value pairs you can create 
> _from_ a literal.
> 
> 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 already familiar. Also 
> “association” and “associative” are confusingly similar, which brings back 
> the is-this-a-dictionary problem.
> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
> different context in Cocoa.
> - `PairCollection`: “Pair” is kinda nondescript.
> - Do nothing. It’s not so bad.
> 
> 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 weight (and instead using `[(Key,Value)]`, which is basically 
> what it’s a wrapper for) is probably off the table for source stability 
> reasons.
> 
> Any further thoughts welcome.
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nevin Brackett-Rozinsky via swift-evolution]

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 varieties) aren't used more
> often is because Swift programmers don't realize they are available and
> easy to implement.
>

Could you provide an example of how you used DictionaryLiteral?

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[charles--- via swift-evolution]

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 easy to 
implement. 

Sent from my telephone

> On Jan 8, 2018, at 9:40 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
>> On Mon, Jan 8, 2018 at 11:53 PM, Xiaodi Wu via swift-evolution 
>>  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 agree on this point. Out of curiosity, why are 
>> there source stability issues to 'typealias DictionaryLiteral = 
>> [(Key, Value)]'?
> 
> Because at the point of use, “DictionaryLiteral” is instantiated with an 
> actual dictionary literal, eg. “[a: 1, b: 2, c: 3]”, and that syntax isn’t 
> available for an array of key-value pairs. As near as I can tell, the 
> convenience of that spelling is the entire raison-d’être for 
> “DictionaryLiteral” in the first place.
> 
> 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, and I doubt 
> it’s being used “in the wild” (I checked several projects in the 
> source-compatibility suite and found zero occurrences).
> 
> Nevin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ben Cohen via swift-evolution]

> 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 address the deprecation warnings). Removing it as not 
 carrying its weight (and instead using `[(Key,Value)]`, which is basically 
 what it’s a wrapper for) is probably off the table for source stability 
 reasons.
>>> 
>>> I’m not familiar with this type at all, so I apologize for the dumb 
>>> question but… why was this added in the first place?  If it is the wrong 
>>> thing, why not just deprecate it in Swift 5 and remove it in a future 
>>> release?  
>> 
>> Given it’s going to be in the ABI regardless, and has at least some marginal 
>> utility, if we can find a more sensible name for it is there any strong 
>> motivation to deprecate it?
> 
> +1 for renaming it to something that isn’t super confusing, but +100 for 
> removing it outright.
> 
> Rationale: if we didn’t have this functionality in the stdlib today, we would 
> not consider adding it.  It doesn’t meet the bar we’ve set for what is in the 
> standard library.  It only exists there by historical accident.  The Mirror 
> API was not carefully considered.
> 

Personally, I feel like this argument for removal as past its use-by date. It 
was a good reason for Swift 3, tenuous for 4 and should be ruled out for 5, 
since the source stability bar has been raised since. Like I said, IMO the 
criteria should now be “active harm”. I also don’t think searches of GitHub etc 
are sufficient justification, except when combined with the active-harm 
argument. I also don’t think the origin story of the type – whether accidental 
or intentional – is relevant to the decision of what to do with it now. It 
exists and people can legitimately use it for their own purposes independent of 
mirrors.

>>> Finally, is anyone actually using this type?
>>> 
>> 
>> 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).
> 
> It directly impacts code size for applications of swift that use the standard 
> library as a standard library, e.g. a raspberry pi dev situation.  It is also 
> bloat, and also takes us down a slippery slope by allowing people to say “if 
> that weird thing is in, why can’t I add my own narrow enhancement?”
> 

The bar for removal and the bar for additions are different. I don’t buy the 
slippery slope argument, and surely neither would anyone else if it were used 
as a justification for new frivolous additions, so this seems like a non-issue 
to me.

> 
> 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 them to something better (and I’m not aware of one 
pending), the plan is they are what they are, at least the public API of 
Swift.Mirror. I would guess this whole area is a candidate to be overhauled 
significantly at some point in the post-Swift 5 future with some more 
fully-fledged reflection system, but there is little chance of this happening 
before ABI stability, and interim tinkering doesn’t seem worthwhile to me.

> -Chris


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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

> 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 its weight (and instead using `[(Key,Value)]`, which is basically 
>>> what it’s a wrapper for) is probably off the table for source stability 
>>> reasons.
>> 
>> I’m not familiar with this type at all, so I apologize for the dumb question 
>> but… why was this added in the first place?  If it is the wrong thing, why 
>> not just deprecate it in Swift 5 and remove it in a future release?  
> 
> Given it’s going to be in the ABI regardless, and has at least some marginal 
> utility, if we can find a more sensible name for it is there any strong 
> motivation to deprecate it?

+1 for renaming it to something that isn’t super confusing, but +100 for 
removing it outright.

Rationale: if we didn’t have this functionality in the stdlib today, we would 
not consider adding it.  It doesn’t meet the bar we’ve set for what is in the 
standard library.  It only exists there by historical accident.  The Mirror API 
was not carefully considered.

>> Finally, is anyone actually using this type?
>> 
> 
> 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).

It directly impacts code size for applications of swift that use the standard 
library as a standard library, e.g. a raspberry pi dev situation.  It is also 
bloat, and also takes us down a slippery slope by allowing people to say “if 
that weird thing is in, why can’t I add my own narrow enhancement?”


More to the point though, this seems like an implementation detail of Mirrors.  
What is the plan for Mirrors + ABI stability?

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

> 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 details better for 
> your use case.

Right.  The functionality can be moved out to a third party package outside the 
stdlib, or copied directly into a project that needs it (worse case).  We’re 
not removing the ability for Swift code to do this, just talking about removing 
it from the swift standard library (which has a very high bar for 
functionality).

-Chris

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ben Cohen via swift-evolution]

> On Jan 8, 2018, at 10:12 PM, Chris Lattner  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 Stability, because 
>> it’s confusingly misnamed, being neither a Dictionary (it doesn’t provide 
>> key-based lookup of values) nor a Literal. 
>> 
>> Instead, it’s just an immutable collection of key-value pairs you can create 
>> _from_ a literal.
> 
> Wow.  This is really gross, I didn’t know it existed :-)
> 
> Random question for you.  DictionaryLiteral has this doc comment:
> 
> /// You initialize a `DictionaryLiteral` instance using a Swift dictionary
> /// literal. Besides maintaining the order of the original dictionary literal,
> /// `DictionaryLiteral` also allows duplicates keys. For example:
> 
> why is maintaining duplicate keys a feature?
> 

Allowing duplicate keys can be useful depending on the use case.  Though you 
could argue they shouldn’t be called keys then…

This type can be described as “just an ordered immutable list of pairs that you 
can declare using the `[:]` syntax because that looks nicer than `[(,)]`” . 
Allowing duplicate keys, and preserving declaration order, is just what it does.

One thought I had was we could replace it with conditional conformance by 
making `Array: ExpressibleByDictionaryLiteral where Element = (Key,Value)`. But 
we can’t do that quite yet, because I think it needs [parameterized 
extensions](https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions
 
).
 Also that might be confusing too ("huh, I can create an array from a 
dictionary literal???”).

> 
> It also has this one:
> 
> /// Some operations that are efficient on a dictionary are slower when using
> /// `DictionaryLiteral`. In particular, to find the value matching a key, you
> /// must search through every element of the collection. The call to
> /// `index(where:)` in the following example must traverse the whole
> /// collection to find the element that matches the predicate:
> 
> Since it is immutable, why not sort the keys in the initializer, allowing an 
> efficient binary search to look up values?
> 

Because it’s currently in user-declared order, like an array. I don’t think we 
could change that without breaking any code that uses it for what it does 
today. Here’s an example in the wild that is reliant on preserving order:
https://github.com/apple/swift/blob/master/benchmark/single-source/RomanNumbers.swift#L28
 
.

We will hopefully add a value-type sorted dictionary too, at some point, which 
would cover the sorted literal use case.

> 
>> 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 already familiar. 
>> Also “association” and “associative” are confusingly similar, which brings 
>> back the is-this-a-dictionary problem.
>> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
>> different context in Cocoa.
>> - `PairCollection`: “Pair” is kinda nondescript.
>> - Do nothing. It’s not so bad.
>> 
>> 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 weight (and instead using `[(Key,Value)]`, which is basically 
>> what it’s a wrapper for) is probably off the table for source stability 
>> reasons.
> 
> I’m not familiar with this type at all, so I apologize for the dumb question 
> but… why was this added in the first place?  If it is the wrong thing, why 
> not just deprecate it in Swift 5 and remove it in a future release?  

Given it’s going to be in the ABI regardless, and has at least some marginal 
utility, if we can find a more sensible name for it is there any strong 
motivation to deprecate it?

> That avoids it being an ABI concern, because we could make it be force 
> inlined into any client code.
> 

"we could make it be force inlined into any client code” isn’t a feature we 
currently plan on having unfortunately. Also this is a type rather than just a 
method, so we’d need a feature to always emit the symbol into the client too.

> Finally, is anyone actually using this type?
> 

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).

> -Chris
> 
> 
> 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Gwendal Roué via swift-evolution]

> Le 9 janv. 2018 à 18:18, Nate Cook  a écrit :
> 
>> 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 
>>> > 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 stdlib *requires* some speculation about use cases, 
>> and speculation is *helped* by the exposition of actual uses. I'm not sure 
>> readers of the mailing list had any idea of the use cases of the current 
>> DictionaryLiteral, and maybe I helped a little.
>> 
>>> Reproducing its feature set is extremely trivial, and would probably allow 
>>> you to hint the implementation details better for your use case.
>> 
>> Please define "trivial”.
>> 
>> In case anybody would wonder, in the line below the `row` variable is of 
>> type Row which happens to adopt ExpressibleByDictionaryLiteral. It is not of 
>> type DictionaryLiteral. The use case here is the ability to express a row 
>> with a dictionary literal that accepts duplicated keys and preserves 
>> ordering:
>> 
>>  XCTAssertEqual(row, ["a": 1, "a": 2])
> 
> That’s great! In this case you aren’t using the DictionaryLiteral type, but a 
> “dictionary literal”, which no one is suggesting we remove.

You're right ! I was almost sure that ExpressibleByDictionaryLiteral 
initializer would eat a DictionaryLiteral, but it doesn't!

extension Row : ExpressibleByDictionaryLiteral {
init(dictionaryLiteral elements: (String, 
DatabaseValueConvertible?)...) { ... }
}

This code has been written too long ago. I have been mislead, I'd like to 
apologize.

> If I’m understanding what you wrote, this is another case where the terrible 
> name is making it super hard to discuss what we’re talking about. “Dictionary 
> literals” and the ExpressibleByDictionaryLiteral protocol are safe!

Yes, I have been bitten hard by the names! Time for bikeshedding indeed :-)

Gwendal

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Eneko Alonso via swift-evolution]

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 is valid SQL and that storing the results on a Dictionary wouldn’t be 
possible without manipulation.

Thus, using DictionaryLiteral (aka TableRow) would make much sense. Users could 
then convert to a Dictionary with the new unifyingKeys initializer, or 
“deserialize” into custom models that can be initialized with the TableRow 
(maybe via Decodable).

Given a proper name, this type could be really useful in many cases.

Thanks,
Eneko


> On Jan 9, 2018, at 9:28 AM, Eneko Alonso via swift-evolution 
>  wrote:
> 
> 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 for table rows)
> - SortedDictionary (sorted dictionaries are missing on the standard library, 
> and could give a chance to make this type more widely used)
> 
> 
> Thanks,
> Eneko 
> 
> 
> 
> 
>> On Jan 9, 2018, at 9:19 AM, Nate Cook via swift-evolution 
>> > wrote:
>> 
>>> 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 
 > 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 stdlib *requires* some speculation about use cases, 
>>> and speculation is *helped* by the exposition of actual uses. I'm not sure 
>>> readers of the mailing list had any idea of the use cases of the current 
>>> DictionaryLiteral, and maybe I helped a little.
>>> 
 Reproducing its feature set is extremely trivial, and would probably allow 
 you to hint the implementation details better for your use case.
>>> 
>>> Please define "trivial”.
>>> 
>>> In case anybody would wonder, in the line below the `row` variable is of 
>>> type Row which happens to adopt ExpressibleByDictionaryLiteral. It is not 
>>> of type DictionaryLiteral. The use case here is the ability to express a 
>>> row with a dictionary literal that accepts duplicated keys and preserves 
>>> ordering:
>>> 
>>> XCTAssertEqual(row, ["a": 1, "a": 2])
>> 
>> That’s great! In this case you aren’t using the DictionaryLiteral type, but 
>> a “dictionary literal”, which no one is suggesting we remove. If I’m 
>> understanding what you wrote, this is another case where the terrible name 
>> is making it super hard to discuss what we’re talking about. “Dictionary 
>> literals” and the ExpressibleByDictionaryLiteral protocol are safe!
>> 
>>> I don't see how anything could better fit this use case than the current 
>>> DictionaryLiteral. This is not *my* use case, but the use case of anyone 
>>> that wants to model database rows beyond the traditional (and ill-advised) 
>>> dictionary.
>>> 
>>> Some other users may come with other use cases that may also help the 
>>> stdlib designers choose the best solution.
>>> 
>>> Gwendal
>>> 
 
 Zach
 z...@waldowski.me 
 
 
 On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
> 
>> 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 
>>> > 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, and I 
>>> doubt it’s being used “in the wild” (I checked several projects in the 
>>> source-compatibility suite and found zero occurrences).
>> 
>> DictionaryLiteral is worthwhile. The SQLite library GRDB uses 
>> DictionaryLiteral in order to build database rows (which may have 
>> duplicated column names, and whose column ordering is important). This 
>> is mostly useful for tests:
>> 
>> let row = try Row.fetchOne(db, "SELECT 1 AS a, 2 AS a")!
>> XCTAssertEqual(row, ["a": 1, "a": 2])
>> 
>> Gwendal
> 
> Chris Lattner's wrote:
> 
>> 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Eneko Alonso via swift-evolution]

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 for table rows)
- SortedDictionary (sorted dictionaries are missing on the standard library, 
and could give a chance to make this type more widely used)


Thanks,
Eneko 




> On Jan 9, 2018, at 9:19 AM, Nate Cook via swift-evolution 
>  wrote:
> 
>> 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 
>>> > 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 stdlib *requires* some speculation about use cases, 
>> and speculation is *helped* by the exposition of actual uses. I'm not sure 
>> readers of the mailing list had any idea of the use cases of the current 
>> DictionaryLiteral, and maybe I helped a little.
>> 
>>> Reproducing its feature set is extremely trivial, and would probably allow 
>>> you to hint the implementation details better for your use case.
>> 
>> Please define "trivial”.
>> 
>> In case anybody would wonder, in the line below the `row` variable is of 
>> type Row which happens to adopt ExpressibleByDictionaryLiteral. It is not of 
>> type DictionaryLiteral. The use case here is the ability to express a row 
>> with a dictionary literal that accepts duplicated keys and preserves 
>> ordering:
>> 
>>  XCTAssertEqual(row, ["a": 1, "a": 2])
> 
> That’s great! In this case you aren’t using the DictionaryLiteral type, but a 
> “dictionary literal”, which no one is suggesting we remove. If I’m 
> understanding what you wrote, this is another case where the terrible name is 
> making it super hard to discuss what we’re talking about. “Dictionary 
> literals” and the ExpressibleByDictionaryLiteral protocol are safe!
> 
>> I don't see how anything could better fit this use case than the current 
>> DictionaryLiteral. This is not *my* use case, but the use case of anyone 
>> that wants to model database rows beyond the traditional (and ill-advised) 
>> dictionary.
>> 
>> Some other users may come with other use cases that may also help the stdlib 
>> designers choose the best solution.
>> 
>> Gwendal
>> 
>>> 
>>> Zach
>>> z...@waldowski.me 
>>> 
>>> 
>>> On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
 
> 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 
>> > 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, and I 
>> doubt it’s being used “in the wild” (I checked several projects in the 
>> source-compatibility suite and found zero occurrences).
> 
> DictionaryLiteral is worthwhile. The SQLite library GRDB uses 
> DictionaryLiteral in order to build database rows (which may have 
> duplicated column names, and whose column ordering is important). This is 
> mostly useful for tests:
> 
> let row = try Row.fetchOne(db, "SELECT 1 AS a, 2 AS a")!
> XCTAssertEqual(row, ["a": 1, "a": 2])
> 
> Gwendal
 
 Chris Lattner's wrote:
 
> why is maintaining duplicate keys a feature?
 
> Since it is immutable, why not sort the keys in the initializer, allowing 
> an efficient binary search to look up values?
 
 
 I really wish both duplicated keys and key ordering would be preserved, 
 since both are needed for the above sample code.
 
 Should those features be lost, the sky wouldn't fall, that's sure. But 
 we'd have to write something much less easy to wrote and read:
 
 XCTAssertEqual(row.map { $0 }, [("a", 1), ("a", 2)])
 
 Gwendal
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nate Cook via swift-evolution]

> 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 
>> > 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 stdlib *requires* some speculation about use cases, 
> and speculation is *helped* by the exposition of actual uses. I'm not sure 
> readers of the mailing list had any idea of the use cases of the current 
> DictionaryLiteral, and maybe I helped a little.
> 
>> Reproducing its feature set is extremely trivial, and would probably allow 
>> you to hint the implementation details better for your use case.
> 
> Please define "trivial”.
> 
> In case anybody would wonder, in the line below the `row` variable is of type 
> Row which happens to adopt ExpressibleByDictionaryLiteral. It is not of type 
> DictionaryLiteral. The use case here is the ability to express a row with a 
> dictionary literal that accepts duplicated keys and preserves ordering:
> 
>   XCTAssertEqual(row, ["a": 1, "a": 2])

That’s great! In this case you aren’t using the DictionaryLiteral type, but a 
“dictionary literal”, which no one is suggesting we remove. If I’m 
understanding what you wrote, this is another case where the terrible name is 
making it super hard to discuss what we’re talking about. “Dictionary literals” 
and the ExpressibleByDictionaryLiteral protocol are safe!

> I don't see how anything could better fit this use case than the current 
> DictionaryLiteral. This is not *my* use case, but the use case of anyone that 
> wants to model database rows beyond the traditional (and ill-advised) 
> dictionary.
> 
> Some other users may come with other use cases that may also help the stdlib 
> designers choose the best solution.
> 
> Gwendal
> 
>> 
>> Zach
>> z...@waldowski.me 
>> 
>> 
>> On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
>>> 
 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 
> > 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, and I 
> doubt it’s being used “in the wild” (I checked several projects in the 
> source-compatibility suite and found zero occurrences).
 
 DictionaryLiteral is worthwhile. The SQLite library GRDB uses 
 DictionaryLiteral in order to build database rows (which may have 
 duplicated column names, and whose column ordering is important). This is 
 mostly useful for tests:
 
 let row = try Row.fetchOne(db, "SELECT 1 AS a, 2 AS a")!
 XCTAssertEqual(row, ["a": 1, "a": 2])
 
 Gwendal
>>> 
>>> Chris Lattner's wrote:
>>> 
 why is maintaining duplicate keys a feature?
>>> 
 Since it is immutable, why not sort the keys in the initializer, allowing 
 an efficient binary search to look up values?
>>> 
>>> 
>>> I really wish both duplicated keys and key ordering would be preserved, 
>>> since both are needed for the above sample code.
>>> 
>>> Should those features be lost, the sky wouldn't fall, that's sure. But we'd 
>>> have to write something much less easy to wrote and read:
>>> 
>>> XCTAssertEqual(row.map { $0 }, [("a", 1), ("a", 2)])
>>> 
>>> Gwendal
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Gwendal Roué via swift-evolution]

> 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 stdlib *requires* some speculation about use cases, and 
speculation is *helped* by the exposition of actual uses. I'm not sure readers 
of the mailing list had any idea of the use cases of the current 
DictionaryLiteral, and maybe I helped a little.

> Reproducing its feature set is extremely trivial, and would probably allow 
> you to hint the implementation details better for your use case.

Please define "trivial".

In case anybody would wonder, in the line below the `row` variable is of type 
Row which happens to adopt ExpressibleByDictionaryLiteral. It is not of type 
DictionaryLiteral. The use case here is the ability to express a row with a 
dictionary literal that accepts duplicated keys and preserves ordering:

XCTAssertEqual(row, ["a": 1, "a": 2])

I don't see how anything could better fit this use case than the current 
DictionaryLiteral. This is not *my* use case, but the use case of anyone that 
wants to model database rows beyond the traditional (and ill-advised) 
dictionary.

Some other users may come with other use cases that may also help the stdlib 
designers choose the best solution.

Gwendal

> 
> Zach
> z...@waldowski.me 
> 
> 
> On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
>> 
>>> 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 
 > 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, and I 
 doubt it’s being used “in the wild” (I checked several projects in the 
 source-compatibility suite and found zero occurrences).
>>> 
>>> DictionaryLiteral is worthwhile. The SQLite library GRDB uses 
>>> DictionaryLiteral in order to build database rows (which may have 
>>> duplicated column names, and whose column ordering is important). This is 
>>> mostly useful for tests:
>>> 
>>> let row = try Row.fetchOne(db, "SELECT 1 AS a, 2 AS a")!
>>> XCTAssertEqual(row, ["a": 1, "a": 2])
>>> 
>>> Gwendal
>> 
>> Chris Lattner's wrote:
>> 
>>> why is maintaining duplicate keys a feature?
>> 
>>> Since it is immutable, why not sort the keys in the initializer, allowing 
>>> an efficient binary search to look up values?
>> 
>> 
>> I really wish both duplicated keys and key ordering would be preserved, 
>> since both are needed for the above sample code.
>> 
>> Should those features be lost, the sky wouldn't fall, that's sure. But we'd 
>> have to write something much less easy to wrote and read:
>> 
>> XCTAssertEqual(row.map { $0 }, [("a", 1), ("a", 2)])
>> 
>> Gwendal
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Gwendal Roué via swift-evolution]

> 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 
>> > 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, and I doubt 
>> it’s being used “in the wild” (I checked several projects in the 
>> source-compatibility suite and found zero occurrences).
> 
> DictionaryLiteral is worthwhile. The SQLite library GRDB uses 
> DictionaryLiteral in order to build database rows (which may have duplicated 
> column names, and whose column ordering is important). This is mostly useful 
> for tests:
> 
> let row = try Row.fetchOne(db, "SELECT 1 AS a, 2 AS a")!
> XCTAssertEqual(row, ["a": 1, "a": 2])
> 
> Gwendal

Chris Lattner's wrote:

> why is maintaining duplicate keys a feature?

> Since it is immutable, why not sort the keys in the initializer, allowing an 
> efficient binary search to look up values?

I really wish both duplicated keys and key ordering would be preserved, since 
both are needed for the above sample code.

Should those features be lost, the sky wouldn't fall, that's sure. But we'd 
have to write something much less easy to wrote and read:

XCTAssertEqual(row.map { $0 }, [("a", 1), ("a", 2)])

Gwendal

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nate Cook via swift-evolution]

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 Stability, because 
>> it’s confusingly misnamed, being neither a Dictionary (it doesn’t provide 
>> key-based lookup of values) nor a Literal. 
>> 
>> Instead, it’s just an immutable collection of key-value pairs you can create 
>> _from_ a literal.
> 
> Wow.  This is really gross, I didn’t know it existed :-)
> 
> Random question for you.  DictionaryLiteral has this doc comment:
> 
> /// You initialize a `DictionaryLiteral` instance using a Swift dictionary
> /// literal. Besides maintaining the order of the original dictionary literal,
> /// `DictionaryLiteral` also allows duplicates keys. For example:
> 
> why is maintaining duplicate keys a feature?
> 
> 
> It also has this one:
> 
> /// Some operations that are efficient on a dictionary are slower when using
> /// `DictionaryLiteral`. In particular, to find the value matching a key, you
> /// must search through every element of the collection. The call to
> /// `index(where:)` in the following example must traverse the whole
> /// collection to find the element that matches the predicate:
> 
> Since it is immutable, why not sort the keys in the initializer, allowing an 
> efficient binary search to look up values?
> 
> 
>> 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 already familiar. 
>> Also “association” and “associative” are confusingly similar, which brings 
>> back the is-this-a-dictionary problem.
>> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
>> different context in Cocoa.
>> - `PairCollection`: “Pair” is kinda nondescript.
>> - Do nothing. It’s not so bad.
>> 
>> 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 weight (and instead using `[(Key,Value)]`, which is basically 
>> what it’s a wrapper for) is probably off the table for source stability 
>> reasons.
> 
> I’m not familiar with this type at all, so I apologize for the dumb question 
> but… why was this added in the first place?  If it is the wrong thing, why 
> not just deprecate it in Swift 5 and remove it in a future release?  That 
> avoids it being an ABI concern, because we could make it be force inlined 
> into any client code.

According to now-gone doc comments, it's intended to be used when providing the 
children for a custom mirror (that's the only API I know of that uses the 
type). The order of elements there is important, but given how scarcely used 
the type is, an array of tuples might be a reasonable (though source-breaking) 
substitute. 

> Finally, is anyone actually using this type?

In the standard library, we have this Mirror initializer: 
https://developer.apple.com/documentation/swift/mirror/1540408-init. If anyone 
is customizing their type's mirror, it's a good bet that they're calling that 
init and passing a literal that would break if the argument changed to an 
array. The translation should be mechanical, so maybe it could be a migrator 
fix? (I don't know enough about how that works to know.)

> 
> -Chris
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Gwendal Roué via swift-evolution]

> 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, and I doubt 
> it’s being used “in the wild” (I checked several projects in the 
> source-compatibility suite and found zero occurrences).

DictionaryLiteral is worthwhile. The SQLite library GRDB uses DictionaryLiteral 
in order to build database rows (which may have duplicated column names, and 
whose column ordering is important). This is mostly useful for tests:

let row = try Row.fetchOne(db, "SELECT 1 AS a, 2 AS a")!
XCTAssertEqual(row, ["a": 1, "a": 2])

Gwendal___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner via swift-evolution]

> 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 
> key-based lookup of values) nor a Literal. 
> 
> Instead, it’s just an immutable collection of key-value pairs you can create 
> _from_ a literal.

Wow.  This is really gross, I didn’t know it existed :-)

Random question for you.  DictionaryLiteral has this doc comment:

/// You initialize a `DictionaryLiteral` instance using a Swift dictionary
/// literal. Besides maintaining the order of the original dictionary literal,
/// `DictionaryLiteral` also allows duplicates keys. For example:

why is maintaining duplicate keys a feature?


It also has this one:

/// Some operations that are efficient on a dictionary are slower when using
/// `DictionaryLiteral`. In particular, to find the value matching a key, you
/// must search through every element of the collection. The call to
/// `index(where:)` in the following example must traverse the whole
/// collection to find the element that matches the predicate:

Since it is immutable, why not sort the keys in the initializer, allowing an 
efficient binary search to look up values?


> 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 already familiar. Also 
> “association” and “associative” are confusingly similar, which brings back 
> the is-this-a-dictionary problem.
> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
> different context in Cocoa.
> - `PairCollection`: “Pair” is kinda nondescript.
> - Do nothing. It’s not so bad.
> 
> 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 weight (and instead using `[(Key,Value)]`, which is basically 
> what it’s a wrapper for) is probably off the table for source stability 
> reasons.

I’m not familiar with this type at all, so I apologize for the dumb question 
but… why was this added in the first place?  If it is the wrong thing, why not 
just deprecate it in Swift 5 and remove it in a future release?  That avoids it 
being an ABI concern, because we could make it be force inlined into any client 
code.

Finally, is anyone actually using this type?

-Chris



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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Xiaodi Wu via swift-evolution]

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 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> Value> = [(Key, Value)]'?
>
>
> Because at the point of use, “DictionaryLiteral” is instantiated with an
> actual dictionary literal, eg. “[a: 1, b: 2, c: 3]”, and that syntax isn’t
> available for an array of key-value pairs.
>

Why do we need available syntax? Sure, conformance of [(Key, Value)] to
ExpressibleByDictionaryLiteral can't be written in Swift, but we could make
this a built-in conformance. Literals are magical in many ways no matter
what.

As near as I can tell, the convenience of that spelling is the entire
> *raison-d’être* for “DictionaryLiteral” in the first place.
>
> 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, and I
> doubt it’s being used “in the wild” (I checked several projects in the
> source-compatibility suite and found zero occurrences).
>

I have seen examples where its use is encouraged, and I see no reason to
address this "ulterior question."

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nevin Brackett-Rozinsky via swift-evolution]

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 agree on this point. Out of curiosity, why are
> there source stability issues to 'typealias DictionaryLiteral =
> [(Key, Value)]'?


Because at the point of use, “DictionaryLiteral” is instantiated with an
actual dictionary literal, eg. “[a: 1, b: 2, c: 3]”, and that syntax isn’t
available for an array of key-value pairs. As near as I can tell, the
convenience of that spelling is the entire *raison-d’être* for
“DictionaryLiteral” in the first place.

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, and I
doubt it’s being used “in the wild” (I checked several projects in the
source-compatibility suite and found zero occurrences).

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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Xiaodi Wu via swift-evolution]

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 =
[(Key, Value)]'?
On Mon, Jan 8, 2018 at 23:25 Nate Cook  wrote:

>
> 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 confusion is why we really need to rename this—there are two separate
> things:
>
> 1) *Dictionary literals.* These are written as comma-separated key-value
> pairs, with each key-value pair separated by a colon—[a: b, c: d, e: f].
> Most users of Swift have probably only ever used these to create instances
> of the Dictionary type, but any type that conforms to
> ExpressibleByDictionaryLiteral can be expressed using one. Crucially, like
> integer literals that can express an `Int` value, a `UInt8` value, or a
> value of any other integer or floating-point type, dictionary literals have 
> *no
> concrete type* until they’re evaluated in context.
>
> 2) *The `DictionaryLiteral` type.* This is a generic type that conforms
> to ExpressibleByDictionaryLiteral, but is otherwise an unremarkable
> collection with `(Key, Value)` elements. You can see its declaration here:
> https://github.com/apple/swift/blob/master/stdlib/public/core/Mirror.swift#L855.
> Despite the name, `DictionaryLiteral` is not a literal—it’s a concrete type
> and can’t be used to express dictionaries or other types that conform to
> `ExpressibleByDictionaryLiteral`.
>
> It’s #2 that we’re talking about renaming, and while I think both parts of
> the name (“Dictionary” and “Literal”) are inaccurate, “Literal” is more
> problematic because of the confusion it causes with lower-case literals.
>
> Nate
>
> Yes, it's not a dictionary, but neither is an integer literal an integer
> (or even necessarily an integer you can create from such a literal: it can
> be a floating-point value you create from that literal), etc. Would
> "ordered collection of key-value pairs" be more "correct"? By the same
> token, we ought to be renaming integer literals "ordered collection of
> digits without interposed decimal point."
>
> But essentially every user will have encountered this spelling in the
> context of dictionaries: in other words, its name has a good basis in
> reality because it is the (only) literal spelling that can be used to
> create a dictionary, and when you say "hey, that spelling you use for a
> literal to instantiate a dictionary in Swift," everyone will know what
> you're talking about.
>
> No, I think we ought to do nothing. It's not only "not bad," but as far as
> I can tell quite superior to the alternatives in essentially every respect.
> In the alternative, maybe "KeyValueLiteral" or something of that sort, but
> I still would consider that to be strictly inferior to "DictionaryLiteral".
>
>
> On Mon, Jan 8, 2018 at 20:24 Nate Cook via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jan 8, 2018, at 6:29 PM, Ben Cohen via swift-evolution <
>> swift-evolution@swift.org> 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
>> key-based lookup of values) nor a Literal.
>> >
>> > Instead, it’s just an immutable collection of key-value pairs you can
>> create _from_ a literal.
>> >
>> > 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 already familiar.
>> Also “association” and “associative” are confusingly similar, which brings
>> back the is-this-a-dictionary problem.
>> > - `KeyValueCollection`: Problematic because key-value comes up in a
>> totally different context in Cocoa.
>> > - `PairCollection`: “Pair” is kinda nondescript.
>> > - Do nothing. It’s not so bad.
>>
>> Agreed so far, and I'd like to add CollectionOfPairs to the list.
>>
>> Some more fun facts about this type:
>> - Besides Dictionary, it's the only other type in the standard library
>> that is expressible by a dictionary literal
>> - Unlike Dictionary, it *does* maintain the order of its pairs
>> - Unlike Dictionary (part 2), it *doesn't* require the first element of
>> the pairs to be Hashable
>>
>> Nate
>>
>> > 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 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nate Cook via swift-evolution]

> 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 confusion is why we really need to rename this—there are two separate 
things:

1) Dictionary literals. These are written as comma-separated key-value pairs, 
with each key-value pair separated by a colon—[a: b, c: d, e: f]. Most users of 
Swift have probably only ever used these to create instances of the Dictionary 
type, but any type that conforms to ExpressibleByDictionaryLiteral can be 
expressed using one. Crucially, like integer literals that can express an `Int` 
value, a `UInt8` value, or a value of any other integer or floating-point type, 
dictionary literals have no concrete type until they’re evaluated in context.

2) The `DictionaryLiteral` type. This is a generic type that conforms to 
ExpressibleByDictionaryLiteral, but is otherwise an unremarkable collection 
with `(Key, Value)` elements. You can see its declaration here: 
https://github.com/apple/swift/blob/master/stdlib/public/core/Mirror.swift#L855.
 Despite the name, `DictionaryLiteral` is not a literal—it’s a concrete type 
and can’t be used to express dictionaries or other types that conform to 
`ExpressibleByDictionaryLiteral`.

It’s #2 that we’re talking about renaming, and while I think both parts of the 
name (“Dictionary” and “Literal”) are inaccurate, “Literal” is more problematic 
because of the confusion it causes with lower-case literals.

Nate

> Yes, it's not a dictionary, but neither is an integer literal an integer (or 
> even necessarily an integer you can create from such a literal: it can be a 
> floating-point value you create from that literal), etc. Would "ordered 
> collection of key-value pairs" be more "correct"? By the same token, we ought 
> to be renaming integer literals "ordered collection of digits without 
> interposed decimal point."
> 
> But essentially every user will have encountered this spelling in the context 
> of dictionaries: in other words, its name has a good basis in reality because 
> it is the (only) literal spelling that can be used to create a dictionary, 
> and when you say "hey, that spelling you use for a literal to instantiate a 
> dictionary in Swift," everyone will know what you're talking about. 
> 
> No, I think we ought to do nothing. It's not only "not bad," but as far as I 
> can tell quite superior to the alternatives in essentially every respect. In 
> the alternative, maybe "KeyValueLiteral" or something of that sort, but I 
> still would consider that to be strictly inferior to "DictionaryLiteral".
> 
> 
>> On Mon, Jan 8, 2018 at 20:24 Nate Cook via swift-evolution 
>>  wrote:
>> 
>> > 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 
>> > key-based lookup of values) nor a Literal.
>> >
>> > Instead, it’s just an immutable collection of key-value pairs you can 
>> > create _from_ a literal.
>> >
>> > 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 already familiar. 
>> > Also “association” and “associative” are confusingly similar, which brings 
>> > back the is-this-a-dictionary problem.
>> > - `KeyValueCollection`: Problematic because key-value comes up in a 
>> > totally different context in Cocoa.
>> > - `PairCollection`: “Pair” is kinda nondescript.
>> > - Do nothing. It’s not so bad.
>> 
>> Agreed so far, and I'd like to add CollectionOfPairs to the list.
>> 
>> Some more fun facts about this type:
>> - Besides Dictionary, it's the only other type in the standard library that 
>> is expressible by a dictionary literal
>> - Unlike Dictionary, it *does* maintain the order of its pairs
>> - Unlike Dictionary (part 2), it *doesn't* require the first element of the 
>> pairs to be Hashable
>> 
>> Nate
>> 
>> > 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 weight (and instead using `[(Key,Value)]`, which is basically 
>> > what it’s a wrapper for) is probably off the table for source stability 
>> > reasons.
>> >
>> > Any further thoughts welcome.
>> >
>> >
>> >
>> > ___
>> > swift-evolution mailing list
>> > 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Xiaodi Wu via swift-evolution]

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 integer
(or even necessarily an integer you can create from such a literal: it can
be a floating-point value you create from that literal), etc. Would
"ordered collection of key-value pairs" be more "correct"? By the same
token, we ought to be renaming integer literals "ordered collection of
digits without interposed decimal point."

But essentially every user will have encountered this spelling in the
context of dictionaries: in other words, its name has a good basis in
reality because it is the (only) literal spelling that can be used to
create a dictionary, and when you say "hey, that spelling you use for a
literal to instantiate a dictionary in Swift," everyone will know what
you're talking about.

No, I think we ought to do nothing. It's not only "not bad," but as far as
I can tell quite superior to the alternatives in essentially every respect.
In the alternative, maybe "KeyValueLiteral" or something of that sort, but
I still would consider that to be strictly inferior to "DictionaryLiteral".


On Mon, Jan 8, 2018 at 20:24 Nate Cook via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 8, 2018, at 6:29 PM, Ben Cohen via swift-evolution <
> swift-evolution@swift.org> 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
> key-based lookup of values) nor a Literal.
> >
> > Instead, it’s just an immutable collection of key-value pairs you can
> create _from_ a literal.
> >
> > 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 already familiar.
> Also “association” and “associative” are confusingly similar, which brings
> back the is-this-a-dictionary problem.
> > - `KeyValueCollection`: Problematic because key-value comes up in a
> totally different context in Cocoa.
> > - `PairCollection`: “Pair” is kinda nondescript.
> > - Do nothing. It’s not so bad.
>
> Agreed so far, and I'd like to add CollectionOfPairs to the list.
>
> Some more fun facts about this type:
> - Besides Dictionary, it's the only other type in the standard library
> that is expressible by a dictionary literal
> - Unlike Dictionary, it *does* maintain the order of its pairs
> - Unlike Dictionary (part 2), it *doesn't* require the first element of
> the pairs to be Hashable
>
> Nate
>
> > 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 weight (and instead using `[(Key,Value)]`, which is basically
> what it’s a wrapper for) is probably off the table for source stability
> reasons.
> >
> > Any further thoughts welcome.
> >
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nate Cook via swift-evolution]

> 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 
> key-based lookup of values) nor a Literal. 
> 
> Instead, it’s just an immutable collection of key-value pairs you can create 
> _from_ a literal.
> 
> 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 already familiar. Also 
> “association” and “associative” are confusingly similar, which brings back 
> the is-this-a-dictionary problem.
> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
> different context in Cocoa.
> - `PairCollection`: “Pair” is kinda nondescript.
> - Do nothing. It’s not so bad.

Agreed so far, and I'd like to add CollectionOfPairs to the list.

Some more fun facts about this type:
- Besides Dictionary, it's the only other type in the standard library that is 
expressible by a dictionary literal
- Unlike Dictionary, it *does* maintain the order of its pairs
- Unlike Dictionary (part 2), it *doesn't* require the first element of the 
pairs to be Hashable

Nate

> 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 weight (and instead using `[(Key,Value)]`, which is basically 
> what it’s a wrapper for) is probably off the table for source stability 
> reasons.
> 
> Any further thoughts welcome.
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ben Cohen via swift-evolution]

> 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 confusingly misnamed, being neither a Dictionary (it doesn’t provide 
>> key-based lookup of values) nor a Literal. 
>> 
>> Instead, it’s just an immutable collection of key-value pairs you can create 
>> _from_ a literal.
>> 
>> 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 already familiar. 
>> Also “association” and “associative” are confusingly similar, which brings 
>> back the is-this-a-dictionary problem.
>> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
>> different context in Cocoa.
>> - `PairCollection`: “Pair” is kinda nondescript.
>> - Do nothing. It’s not so bad.
>> 
>> 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 weight (and instead using `[(Key,Value)]`, which is basically 
>> what it’s a wrapper for) is probably off the table for source stability 
>> reasons.
>> 
>> Any further thoughts welcome.
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> Since it is a generic type, could it not be nested inside of the appropriate 
> Dictionary type? That would make 2 or 3 more reasonable.
> 
> Also, what about Dictionary.KeyValuePairs?
> 
> - Karl

It’s really not related to the Dictionary type. This isn’t part of Dictionary’s 
implementation leaking out, like DictionaryIndex or DictionaryIterator were. 
It’s a separate independently (marginally-) useful type.


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

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Karl Wagner via swift-evolution]

> 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 
> key-based lookup of values) nor a Literal. 
> 
> Instead, it’s just an immutable collection of key-value pairs you can create 
> _from_ a literal.
> 
> 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 already familiar. Also 
> “association” and “associative” are confusingly similar, which brings back 
> the is-this-a-dictionary problem.
> - `KeyValueCollection`: Problematic because key-value comes up in a totally 
> different context in Cocoa.
> - `PairCollection`: “Pair” is kinda nondescript.
> - Do nothing. It’s not so bad.
> 
> 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 weight (and instead using `[(Key,Value)]`, which is basically 
> what it’s a wrapper for) is probably off the table for source stability 
> reasons.
> 
> Any further thoughts welcome.
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


Since it is a generic type, could it not be nested inside of the appropriate 
Dictionary type? That would make 2 or 3 more reasonable.

Also, what about Dictionary.KeyValuePairs?

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