Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

[Dave Abrahams via swift-evolution]

on Fri Oct 14 2016, Paul Cantrell  wrote:

> A late-arriving strong +1 for me. The index-related stuff is elegant and much 
> needed. I’m surprised
> to learn that dict.keys and dict.values are copies and not already
> views! 

They are views.

> Clearly they should be.
>
> Question: I hit a closely related performance wall just last week, doing 
> something like this:
>
> for k in dict.keys {
> dict.values[k].append(1)
> }
>
> I assume / hope the proposal would also support this?
>
> for i in dict.indices {
> dict.values[i].append(1)
> }
>
> …or would it be this?
>
> for i in dict.keys.indices {
> dict.values[i].append(1)
> }
>
> …or either?
>
> Cheers, P
>
>> On Oct 11, 2016, at 4:28 PM, Nate Cook via swift-evolution
>  wrote:
>> 
>> Introduction
>> 
>> This proposal addresses significant unexpected performance gaps when using 
>> dictionaries. It
> introduces type-specific collections for a Dictionary instance's keys and 
> values properties.
>> 
>> New DictionaryKeys and DictionaryValues collections provide efficient key 
>> lookup and mutable access to dictionary values, enabling updates to be 
>> performed in-place and allowing copy-on-write optimization of stored values.
>> 
>>  
>> Motivation
>> 
>> This proposal address two problems:
>> 
>> The Dictionary type keys implementation is inefficient, because 
>> LazyMapCollection doesn't know how to forward lookups to the underlying 
>> dictionary storage.
>> Dictionaries do not offer value-mutating APIs. The mutating key-based 
>> subscript wraps values in an Optional. This prevents types with 
>> copy-on-write optimizations from recognizing they are singly referenced.
>> This proposal uses the following [String: [Int]] dictionary to demonstrate 
>> these problems:
>> 
>> var dict = ["one": [1], "two": [2, 2], "three": [3, 3, 3]]
>>  
>> Inefficient
>>  dict.keys Search
>> 
>> Swift coders normally test key membership using nil checks or underscored 
>> optional bindings:
>> 
>> if dict["one"] != nil {
>> // ...
>> }
>> if let _ = dict["one"] {
>> // ...
>> }
>> These approaches provide the expected performance of a dictionary lookup but 
>> they read neither well nor "Swifty". Checking keys reads much better but 
>> introduces a serious performance penalty: this approach requires a linear 
>> search through a dictionary's keys to find a match.
>> 
>> if dict.keys.contains("one") {
>> // ...
>> }
>> A similar dynamic plays out when comparing dict.index(forKey:) and 
>> dict.keys.index(of:).
>> 
>>  
>> Inefficient
>>  Value Mutation
>> 
>> Dictionary values can be modified through the keyed subscript by direct 
>> reassignment or by using optional chaining. Both of these statements append 
>> 1 to the array stored by the key "one":
>> 
>> // Direct re-assignment
>> dict["one"] = (dict["one"] ?? []) + [1]
>> 
>> // Optional chaining
>> dict["one"]?.append(1)
>> Both approaches present problems. The first is complex and hard to read. The 
>> second ignores the case where "one" is not a key in the dictionary. It 
>> forces its check into a higher branch and encourages forced unwrapping. 
>> Furthermore, neither approach allows the array to grow in place. They 
>> introduce an unnecessary copy of the array's contents even though dict is 
>> the sole holder of its storage.
>> 
>> Adding mutation to a dictionary's index-based subscripting isn't possible. 
>> Changing a key stored at a particular index would almost certainly modify 
>> its hash value, rendering the index incorrect. This violates the 
>> requirements of the MutableCollection protocol.
>> 
>>  
>> Proposed
>>  Solution
>> 
>> This proposal adds a custom collection for the keys and values dictionary 
>> properties. This follows the example set by String, which presents multiple 
>> views of its contents. A new DictionaryKeys collection introduces efficient 
>> key lookup, while a new DictionaryValues collection provides a mutable 
>> collection interface to dictionary values.
>> 
>> These changes introduce a simple and efficient way of checking whether a 
>> dictionary includes a key:
>> 
>> // Performant
>> if dict.keys.contains("one") {
>> // ...
>> }
>> As a mutable collection, values enables modification without copies or 
>> clumsy code:
>> 
>> if let i = dict.index(forKey: "one") {
>> dict.values[i].append(1)  // no copy here
>> } else {
>> dict["one"] = [1]
>> }
>> Both the keys and values collections share the same index type as 
>> Dictionary. This allows the above sample to be rewritten as:
>> 
>> 

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Erica Sadun via swift-evolution]

> On Oct 15, 2016, at 6:41 PM, Charles Constant via swift-evolution 
>  wrote:
> 
> How would we all feel about allowing multiple modules with one import 
> statement? 
> 
> Eg: the option to write
> 
> import Cocoa, Foo, Bar.Baz  
> 
> in addition to just:
> 
> import Cocoa   
> import Foo 
> import Bar.Baz 
> 
> When I'm writing smaller files that import a few modules, I'd  prefer to lump 
> the imports together like this. Doesn't seem like a feature that would 
> require much effort to implement either.

I'm fine with this. I'd also like `import as` to handle namespacing 
simplification and conflict resolution

`import Bar.Baz as Bif`

-- E


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

[swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Charles Constant via swift-evolution]

How would we all feel about allowing multiple modules with one import
statement?

Eg: the option to write

*import Cocoa, Foo, Bar.Baz *

in addition to just:

*import Cocoa   *
*import Foo *
*import Bar.Baz *

When I'm writing smaller files that import a few modules, I'd  prefer to
lump the imports together like this. Doesn't seem like a feature that would
require much effort to implement either.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Tuples as RawRepresentable

[Haravikk via swift-evolution]

> On 15 Oct 2016, at 18:21, Nevin Brackett-Rozinsky 
>  wrote:
> 
> Tuples cannot conform to protocols, so despite the existence of an “==” 
> operator for certain tuples, no tuple conforms to Equatable.
> 
> This is problematic, because it means that a function which takes a generic 
> Equatable parameter cannot be called with a tuple argument, even though an 
> applicable “==” operator exists.
> 
> (Ditto for “Comparable”, mutatis mutandis.)
> 
> Nevin

Yeah, since the operators are implemented though perhaps some kind of magic can 
be used? It seems strange that the following is valid:

struct Foo : Equatable { let value:(Int, Int) }
func == (lhs:Foo, rhs:Foo) -> Bool { return lhs.value == rhs.value }

Yet tuples can't just be Equatable etc. But I'm wondering whether that falls 
into separate issue territory, such that it should be done first as its own 
proposal?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[ted van gaalen via swift-evolution]

in 10-15 years compilers/interpreters are merged and update themselves as AI.
so we can tell in human language what an app should do :o)

@Jean: can you explain that about extensions in this context (oop) ?

TedvG


ted van gaalen

> On 15 Oct 2016, at 21:44, Goffredo Marocchi  wrote:
> 
> We will see how this will fare one way or the other in say 10-15 years.
> 
> Sent from my iPhone
> 
>> On 15 Oct 2016, at 14:43, Jean-Daniel via swift-evolution 
>>  wrote:
>> 
>> 
>>> Le 13 oct. 2016 à 23:27, Ted F.A. van Gaalen  a 
>>> écrit :
>>> 
>>> Please do NOT drop the current distinction between *private* and 
>>> *fileprivate*
>>> as it is now in Swift 3
>>> It is needed for correct OOP.  
>>> 
>> 
>> That argument don’t apply for a language where you can structure your code 
>> in extensions as in Swift.
>> 
>> 
>> ___
>> 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] Tuples as RawRepresentable

[J.E. Schotsman via swift-evolution]

> On 15 Oct 2016, at 19:00, Karl Wagner wrote:
> 
> The edge-case I have in mind is... let's say we synthesised RawRep 
> conformance for all Equatable raw-types. That would allow you use struct and 
> class rawvalues with our shorthand syntax.

I am not saying the compiler should do all the work. It’s OK with me if I have 
to make the rawValue type RawRepresentable myself.

Consider the following code, where Rectangle is a type that is useful on its 
own:

import Cocoa

struct Rectangle: RawRepresentable
{
var width: Int = 0
var height: Int = 0
}

extension Rectangle: RawRepresentable
{
typealias RawValue = String

init( rawValue:String )
{
let values = rawValue.componentsSeparatedByString("x")
if let width = Int(values[0]), let height = Int(values[1]) { self.init( 
width:width, height:height ) }
else { self.init( width:0, height:0 ) }
}

var rawValue:String { return "\(width)x\(height)" }
}

enum RectFormat: Rectangle
{
case SMALL = “30x30"
case MEDIUM = “60x60"
case LARGE = “120x120"

var width: Int { return rawValue.width }
var height: Int { return rawValue.height }
}

let fmt = RectFormat.MEDIUM
print ("width: \(fmt.width) height: \(fmt.height)")

This was written in Xcode and Swift 2.2 (I cannot yet update to Swift 3) and 
does not compile.

Given this Rectangle struct I would like to be able to write

enum RectFormat: Rectangle
{
case SMALL = Rectangle (30,30)
case MEDIUM = Rectangle (60,60)
case LARGE = Rectangle (120,120)
}

let fmt = RectFormat.MEDIUM
print ("width: \(fmt.width) height: \(fmt.height)”)
let fmt2 = RectFormat( rawValue:Rectangle (40,40) ) // fmt2 is nil

IOW no need for literals, no need to copy the properties or methods of 
Rectangle, omit rawValue when accessing them.

If the compiler needs to store the cases as literals we can require RawValue to 
be StringLiteralType, IntegerLiteralType or FloatLiteralType (or a tuple of 
these).
IMHO the developer can take on the responsibility for making sure the mapping 
from and to RawValue is one to one.

I am not sure if this is purely additive sugar (might be, except in case of 
tuples?).

Jan E.

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

Re: [swift-evolution] private & fileprivate

[Goffredo Marocchi via swift-evolution]

We will see how this will fare one way or the other in say 10-15 years.

Sent from my iPhone

> On 15 Oct 2016, at 14:43, Jean-Daniel via swift-evolution 
>  wrote:
> 
> 
>> Le 13 oct. 2016 à 23:27, Ted F.A. van Gaalen  a écrit 
>> :
>> 
>> Please do NOT drop the current distinction between *private* and 
>> *fileprivate*
>> as it is now in Swift 3
>> It is needed for correct OOP.  
>> 
> 
> That argument don’t apply for a language where you can structure your code in 
> extensions as in Swift.
> 
> 
> ___
> 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] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Russ Bishop via swift-evolution]

> On Oct 14, 2016, at 12:59 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" 
> begins now and runs through October 18. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 

-1 from me.

The library in question was exploiting a bug in the compiler. I went and 
checked the officially published Swift 1.0 grammar and “$” is not a valid 
identifier.

I’m sympathetic to the argument that the behavior shipped in three major 
versions but ultimately all this does is create an opportunity for cute tricks.

Russ


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

Re: [swift-evolution] private & fileprivate

[Jean-Daniel via swift-evolution]

> Le 13 oct. 2016 à 23:27, Ted F.A. van Gaalen  a écrit :
> 
> Please do NOT drop the current distinction between *private* and *fileprivate*
> as it is now in Swift 3
> It is needed for correct OOP.  
> 

That argument don’t apply for a language where you can structure your code in 
extensions as in Swift.


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

Re: [swift-evolution] Tuples as RawRepresentable

[Nevin Brackett-Rozinsky via swift-evolution]

Tuples cannot conform to protocols, so despite the existence of an “==”
operator for certain tuples, no tuple conforms to Equatable.

This is problematic, because it means that a function which takes a generic
Equatable parameter cannot be called with a tuple argument, even though an
applicable “==” operator exists.

(Ditto for “Comparable”, *mutatis mutandis*.)

Nevin



On Sat, Oct 15, 2016 at 12:28 PM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 15 Oct 2016, at 16:04, Xiaodi Wu  wrote:
> >
> > Yes it absolutely matters what the types are. Two floating point values
> can compare equal when their raw bytes differ and they can compare not
> equal even when their raw bytes are the same, and it would be absolutely
> necessary that a tuple of two floating point values behaves the same way.
> >
> > Moreover, if a value is not equatable, it's nonsense to ask if tuples of
> two of them are equal. Otherwise, you've effectively forced every value
> type to be equatable, since it'd be ridiculous if (a, a) == (b, b) didn't
> imply a == b.
>
> All I meant really is that you can always compare equality at the memory
> level, regardless of Equatable conformance; the type checker ensures the
> tuples being compared can only contain the same types in the same order, at
> which point a bitwise memory comparison can determine they are equal in the
> strictest possible sense, much like comparing whether two object references
> point to the same object (you're comparing the pointers).
>
> But actually it doesn't seem to even matter; tuples are already Equatable
> if all of their components are (again, something I don't seem to actually
> use), so that should be more than sufficient for using them as enum raw
> values, we can just ignore tuples that aren't/require the developer to add
> Equatable to any components that aren't.
> ___
> 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] Tuples as RawRepresentable

[Saagar Jha via swift-evolution]

If you're looking for a use case for tuple equality, I often pack a bunch
of values in a tuple and check it with another, which makes it easy to
compare a multiple values at once and perform something only if all of them
are equal.

On Sat, Oct 15, 2016 at 09:28 Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 15 Oct 2016, at 16:04, Xiaodi Wu  wrote:
> >
> > Yes it absolutely matters what the types are. Two floating point values
> can compare equal when their raw bytes differ and they can compare not
> equal even when their raw bytes are the same, and it would be absolutely
> necessary that a tuple of two floating point values behaves the same way.
> >
> > Moreover, if a value is not equatable, it's nonsense to ask if tuples of
> two of them are equal. Otherwise, you've effectively forced every value
> type to be equatable, since it'd be ridiculous if (a, a) == (b, b) didn't
> imply a == b.
>
> All I meant really is that you can always compare equality at the memory
> level, regardless of Equatable conformance; the type checker ensures the
> tuples being compared can only contain the same types in the same order, at
> which point a bitwise memory comparison can determine they are equal in the
> strictest possible sense, much like comparing whether two object references
> point to the same object (you're comparing the pointers).
>
> But actually it doesn't seem to even matter; tuples are already Equatable
> if all of their components are (again, something I don't seem to actually
> use), so that should be more than sufficient for using them as enum raw
> values, we can just ignore tuples that aren't/require the developer to add
> Equatable to any components that aren't.
> ___
> 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] Tuples as RawRepresentable

[Haravikk via swift-evolution]

> On 15 Oct 2016, at 16:04, Xiaodi Wu  wrote:
> 
> Yes it absolutely matters what the types are. Two floating point values can 
> compare equal when their raw bytes differ and they can compare not equal even 
> when their raw bytes are the same, and it would be absolutely necessary that 
> a tuple of two floating point values behaves the same way.
> 
> Moreover, if a value is not equatable, it's nonsense to ask if tuples of two 
> of them are equal. Otherwise, you've effectively forced every value type to 
> be equatable, since it'd be ridiculous if (a, a) == (b, b) didn't imply a == 
> b.

All I meant really is that you can always compare equality at the memory level, 
regardless of Equatable conformance; the type checker ensures the tuples being 
compared can only contain the same types in the same order, at which point a 
bitwise memory comparison can determine they are equal in the strictest 
possible sense, much like comparing whether two object references point to the 
same object (you're comparing the pointers).

But actually it doesn't seem to even matter; tuples are already Equatable if 
all of their components are (again, something I don't seem to actually use), so 
that should be more than sufficient for using them as enum raw values, we can 
just ignore tuples that aren't/require the developer to add Equatable to any 
components that aren't.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jonathan Hull via swift-evolution]

>   * What is your evaluation of the proposal?
-1.  I would much rather see it either as an operator, or more likely as some 
other special syntax/meaning in Swift.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
No. Providing backwards compatibility with a single library that used an 
undocumented feature is not a significant enough reason.

>   * Does this proposal fit well with the feel and direction of Swift?
No.
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I read the proposal and previous reviews.

Thanks,
Jon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Tuples as RawRepresentable

[Xiaodi Wu via swift-evolution]

Yes it absolutely matters what the types are. Two floating point values can
compare equal when their raw bytes differ and they can compare not equal
even when their raw bytes are the same, and it would be absolutely
necessary that a tuple of two floating point values behaves the same way.

Moreover, if a value is not equatable, it's nonsense to ask if tuples of
two of them are equal. Otherwise, you've effectively forced every value
type to be equatable, since it'd be ridiculous if (a, a) == (b, b) didn't
imply a == b.

On Sat, Oct 15, 2016 at 19:44 Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 14 Oct 2016, at 19:11, Karl  wrote:
>
>
> On 14 Oct 2016, at 19:56, Haravikk  wrote:
>
> Huh, see, that's why I posted the thread; I didn't know you could do it
> that way (I've been trying the RawRepresentable part as its own type).
> In that case yes, it seems like all that's need is an expansion of what's
> allowable on the rhs of raw value enum cases.
>
>
> And that’s why I come here - to share the little bits that I’ve learned :)
>
> I think a lot of people have misconceptions about what RawRep is, and the
> inheritance syntax for enums doesn’t much help that. It doesn’t affect the
> storage or layout of the enum whatsoever; it’s just a protocol conformance.
> The compiler generates these same kind of switch statements, and that’s
> really the only reason AFAIK that we have the limitations (e.g. int/string
> literal) that we do.
>
> There are no restrictions on what can be RawRepresentable (structs and
> classes can also conform), and no limitation on the type of RawType (can
> also be a struct or a class). You just need to implement it yourself in
> those cases; I’m guessing because there are complex edge-cases which we
> don’t want hidden away in a location you can’t easily debug.
>
> Tuples of Ints and Strings, however, seem like they could easily be
> supported. For example, we could check that there are no overlapping cases.
>
>
> Does the type of the tuples really matter? For equality it should be
> sufficient just to compare them directly as bytes; since they will be of
> the same tuple type this should either result in equality or not without
> too much complexity, otherwise we'd need to require the types are Equatable
> or Hashable but that seems a bit like overkill.
>
> I've started a preliminary proposal for tuples as enum raw value types;
> it's pretty straightforward so far as I'm not sure what more detail is
> really needed, except perhaps for this equality issue:
>
> https://github.com/Haravikk/swift-evolution/blob/master/proposals/-allow-tuples-as-enum-raw-values.md
> ___
> 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] Tuples as RawRepresentable

[Karl Wagner via swift-evolution]

  
  
The edge-case I have in mind is... let's say we synthesised RawRep conformance 
for all Equatable raw-types. That would allow you use struct and class 
rawvalues with our shorthand syntax.
  

  
But Equatable values might overlap. A single raw-value might be considered 
equal to multiple cases in the enum. If you do that, you can get unexpected 
values from the initialiser, and we won't be able to check for it at 
compile-time, and when you try to debug these strange values, it will be in 
some code that isn't written down anywhere and so less obvious to debug. The 
only magic about Int/String literals is that the compiler understands their 
content and that content is known at compile-time so can be checked for 
uniqueness.
  

  
To be clear, though: I don't know really know why that limitation is there; but 
from what I've seen of the implementation this is my best guess. Otherwise 
there's nothing technically stopping us loosening the restrictions for the 
shorthand AFAIK.
  

  

  

  
  
  

  
  
  
  

  
  
>   
> On Oct 15, 2016 at 12:37 pm,   (mailto:swift-evolution@swift.org)>  wrote:
>   
>   
>   
>   
>   
> >   
> > On 15 Oct 2016, at 01:53,Karl wrote:
> >   
>   
> >
> >   
> > There are no restrictions on what can be RawRepresentable (structs and 
> > classes can also conform), and no limitation on the type of RawType (can 
> > also be a struct or a class). You just need to implement it yourself in 
> > those cases; I’m guessing because there are complex edge-cases which we 
> > don’t want hidden away in a location you can’t easily debug.
> >   
>   
>   
>   
> Can you give an example of such an edge case?
>   
> We may be able to exclude them somehow.
>   
>
>   
> Jan E.
>  ___ swift-evolution mailing list 
>  swift-evolution@swift.org (mailto: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] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Georgios Moschovitis via swift-evolution]

> * What is your evaluation of the proposal?

-1 

The only use case of ‘$’ would be in short funny swift examples or in a 
playground, e.g. as a variable for a monetary amount. Similar to the emojis 
used as variables in the wild.

But then, you could just use the ＄emoji…

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

no

> * Does this proposal fit well with the feel and direction of Swift?

no

> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal 
compares to those?

js/jQuery

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

quick read

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

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Anton Zhilin via swift-evolution]

Currently, we can expect that fields of a type are all collected in the
same place. This expectation applies more for "static" and less for
"dynamic" types.
So I agree with the idea for @objc classes, strongly disagree for structs,
and disagree for regular classes.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Tuples as RawRepresentable

[Haravikk via swift-evolution]

> On 14 Oct 2016, at 19:11, Karl  wrote:
> 
> 
>> On 14 Oct 2016, at 19:56, Haravikk > > wrote:
>> 
>> Huh, see, that's why I posted the thread; I didn't know you could do it that 
>> way (I've been trying the RawRepresentable part as its own type).
>> In that case yes, it seems like all that's need is an expansion of what's 
>> allowable on the rhs of raw value enum cases.
>> 
> 
> And that’s why I come here - to share the little bits that I’ve learned :)
> 
> I think a lot of people have misconceptions about what RawRep is, and the 
> inheritance syntax for enums doesn’t much help that. It doesn’t affect the 
> storage or layout of the enum whatsoever; it’s just a protocol conformance. 
> The compiler generates these same kind of switch statements, and that’s 
> really the only reason AFAIK that we have the limitations (e.g. int/string 
> literal) that we do.
> 
> There are no restrictions on what can be RawRepresentable (structs and 
> classes can also conform), and no limitation on the type of RawType (can also 
> be a struct or a class). You just need to implement it yourself in those 
> cases; I’m guessing because there are complex edge-cases which we don’t want 
> hidden away in a location you can’t easily debug.
> 
> Tuples of Ints and Strings, however, seem like they could easily be 
> supported. For example, we could check that there are no overlapping cases.

Does the type of the tuples really matter? For equality it should be sufficient 
just to compare them directly as bytes; since they will be of the same tuple 
type this should either result in equality or not without too much complexity, 
otherwise we'd need to require the types are Equatable or Hashable but that 
seems a bit like overkill.

I've started a preliminary proposal for tuples as enum raw value types; it's 
pretty straightforward so far as I'm not sure what more detail is really 
needed, except perhaps for this equality issue:
https://github.com/Haravikk/swift-evolution/blob/master/proposals/-allow-tuples-as-enum-raw-values.md___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Tuples as RawRepresentable

[J.E. Schotsman via swift-evolution]

> On 15 Oct 2016, at 01:53,Karl wrote:
> 
> There are no restrictions on what can be RawRepresentable (structs and 
> classes can also conform), and no limitation on the type of RawType (can also 
> be a struct or a class). You just need to implement it yourself in those 
> cases; I’m guessing because there are complex edge-cases which we don’t want 
> hidden away in a location you can’t easily debug.

Can you give an example of such an edge case?
We may be able to exclude them somehow.

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

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Benjamin Spratling via swift-evolution]

I’m haven’t read the implementation, but as I see it, “weak” has the effect of 
storing associated values.  Can that mechanism be made generic?

> +1 from me too for internal extensions; I think this is the logical place to 
> start for now so we can see how many use cases this actually covers. 
> Personally I don't try to add functionality to types from other libraries, 
> and when I have to I try as much as possible to do it via wrapping; obviously 
> this doesn't cover the async type cases and others where it'd be hard to 
> re-wrap the values, but I think I'd like to know more about how common such 
> cases actually are.
> 
> However, allowing stored properties in local extensions is an absolute must 
> for a first step, and would be very useful as a first step.
> 
> 
> The problem I have with doing it for external types is that I just don't see 
> how it can be done efficiently; associated objects means looking up the 
> object to find what its associated values are, which isn't a negligible cost 
> if you're doing it frequently, and it makes me very uncomfortable to think of 
> hiding what is actually happening, as developers may think they're just using 
> a regular property without really appreciating the actual costs involved. At 
> the very least they need to handled through a .associated property or 
> whatever to make it much clearer that these aren't native properties in the 
> normal sense.
> ___
> 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] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Haravikk via swift-evolution]

> On 14 Oct 2016, at 20:59, Chris Lattner via swift-evolution 
>  wrote:
> 
>   * What is your evaluation of the proposal?

Not in favour, sorry. While I've used this kind of pattern in Javascript I just 
don't see what it really adds compared to a more explicit name. As a general 
rule I prefer everything to be explicitly named except where a case is 
genuinely trivial (like the dollar syntax for closure arguments).

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

If it had more benefits maybe, but I just don't see them.

>   * Does this proposal fit well with the feel and direction of Swift?

No, I think that allowing the dollar sign could be confusing alongside dollar 
sign variables in closures, and I feel that Swift is better being explicit 
where possible.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

It's similar to a lot of Javascript libraries that use the dollar sign for 
values, but I've never felt that I was really gaining anything significant by 
using it as a variable name.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

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

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Haravikk via swift-evolution]

> On 15 Oct 2016, at 02:01, Paul Cantrell via swift-evolution 
>  wrote:
> 
> 
>> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>> Let extensions introduce stored properties, but only in the same module as 
>> the type’s definition. Then, the compiler can just take any extensions into 
>> consideration when it’s determining the size of the type, just as if the 
>> properties had been declared in the type. Declaring stored properties on an 
>> extension outside of the type’s module results in a compiler error, exactly 
>> as today. This would, without any performance drawbacks, solve one of the 
>> big problems that people are hoping to solve via stored properties in 
>> extensions—the ability to organize members by protocol conformance.
> 
> Yes please! A big strong +1 to this from me. I can think of several specific 
> chunks of problem code that this would clean up immensely.

+1 from me too for internal extensions; I think this is the logical place to 
start for now so we can see how many use cases this actually covers. Personally 
I don't try to add functionality to types from other libraries, and when I have 
to I try as much as possible to do it via wrapping; obviously this doesn't 
cover the async type cases and others where it'd be hard to re-wrap the values, 
but I think I'd like to know more about how common such cases actually are.

However, allowing stored properties in local extensions is an absolute must for 
a first step, and would be very useful as a first step.


The problem I have with doing it for external types is that I just don't see 
how it can be done efficiently; associated objects means looking up the object 
to find what its associated values are, which isn't a negligible cost if you're 
doing it frequently, and it makes me very uncomfortable to think of hiding what 
is actually happening, as developers may think they're just using a regular 
property without really appreciating the actual costs involved. At the very 
least they need to handled through a .associated property or whatever to make 
it much clearer that these aren't native properties in the normal sense.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

[Karl via swift-evolution]

Done. https://bugs.swift.org/browse/SR-2963.

> On 14 Oct 2016, at 22:42, John McCall  wrote:
> 
>> On Oct 11, 2016, at 12:04 AM, Karl via swift-evolution 
>> > wrote:
>>> 
>>> On 11 Oct 2016, at 08:49, Benjamin Spratling >> > wrote:
>>> 
>>> Howdy,
>>> The error message is not saying that aFunction throws, it says “??" might 
>>> throw.  After all, you supplied a ()rethrows->(Int) to it as its second 
>>> argument, which is wrapping a ()throws->Int, “bFunction()"
>>> ?? and && and || wrap the trailing expression in an @autoclosure.
>>> 
>>> I am a little surprised two “try” are not required.  This would be my 
>>> expectation:
 let value = try aFunction() ?? try bFunction()
>>> but, using try to the right of a non-assignment operator is not allowed.
>>> 
>>> This, however, is not disallowed:
>>> 
>>> let value = try aFunction() ?? (try bFunction())
>>> 
>>> The purpose of the @autoclosure is to make developers forget they need to 
>>> write a closure, and it apparently worked for you.
>>> 
>>> -Ben Spratling
>>> 
>> 
>> Yeah, I understand the reason for it, but I still think we should change it 
>> so you write the ‘try’ before the part which actually throws. Perhaps the 
>> rule should be something more general around rethrowing autoclosures?
>> 
>> After all, I thought that was the entire point of the ‘try’ keyword. The 
>> compiler doesn't really need it (it already knows what throws and what 
>> doesn’t), but it helps humans to mark where the throwing stuff happens.
> 
> I agree that you should be able to place the try inside the autoclosure and 
> have that propagate out.  This doesn't need evolution discussion; please file 
> a bug.
> 
> John.

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