Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

>> Swift has proven it can thrive in secrecy, so I don't think the whole open >> community is a necessity — but as it is now, we should hold transparency in >> high esteem and not start faking democracy. > > I’m confused, what are you saying? No decision has been made here, I’m not > aware

Re: [swift-evolution] Better syntax for deferred?

> Unless I missed something obvious, wouldn't placing "code that always has to > run at the end" actually *at the end* not make more sense? Like this… In most cases, you use defer for cleanup tasks - so it make more sense to keep it at the source of the "problem": file.open(); defer {

Re: [swift-evolution] Better syntax for deferred?

I have the terrible feeling something is wrong with my posts so that they get caught by spamfilters or similar… But as others stated as well: defer has a use case that is a little bit different from what you want to archive. > Why not use a solution that is widely used and better? I'm curious:

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> What are those advantages precisely? subjective: Easier to understand objective: Saves keywords/syntax ("…", "memberwise", "@nomemberwise", "required", "convenience", "@default"…) >> What I can see in your example is that the proposed syntax allows me to >> trigger compiler errors that

Re: [swift-evolution] Customized Inline Init Closure

Something similar has been discussed ("method cascading"), and I hope the feature will be considered for Swift 4(?). It is a little bit different, though: "self" would not change its meaning (which imho is a plus), and the syntax is different. Tino

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> The “type parameter list” syntax is sugar that could be implemented as a > layer on top of the current proposal or could be implemented orthogonally. Hi Howard, I've heard this argument before, so I'll repeat my answer as well: Both offers don't make sense, it's either one way or the other (or

Re: [swift-evolution] About the PermutationGenerator

> Those are collections. Collections can be iterated over multiple times. Speaking of the Fibonacci-numbers: Sure we can write an algorithm that iterates over them several times — it just won't ever finish the first iteration ;-) (only nitpicking — I just couldn't resist) Happy new year!

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

> func byComparing(getComparisonKey: (T)->U) -> (T, T) -> > Bool { > return { getComparisonKey($0) < getComparisonKey($1) } > } I've written something similar to bring file URLs into the order of their creation dates. It is a small extension for collection types, and its

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

This is some sort of a cross-post from another thread ["automatic protocol forwarding"] — for anyone who wants to follow, I recommend to read https://kotlinlang.org/docs/reference/classes.html The idea of "function-like class declaration" has

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> I don’t want this thread to get distracted with memberwise initialization Makes sense in general, but Kotlin solves those problems as a whole, and the major benefit of their approach is that everything fits together really fine. But I'll skip everything that is not related to forwarding. >

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

> Ah good point, in swift you can return a function as a closure (see that > link) so interface builder could bind an action. afaics this cannot work when myClass is nil: The transponder chain might be invisible on iOS, but for OS X, it is vital. Tino

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

>> I deny that, and even if it is true, there is a price to pay — and that is >> more than the lines of code that are required… > > Personally, I think it is a lot more readable to put members separate lines, > but if you don’t like doing that: You are focusing on the least important thing here

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

I'm not opposing the proposal, but I wonder why there has been such a big discussion (and a poll whose results have neither been revealed completely nor affected the choice of the keyword)… Swift has proven it can thrive in secrecy, so I don't think the whole open community is a necessity —

Re: [swift-evolution] Final by default for classes and methods

> Obviously there are some things where you really don't need to call super > (mostly abstract methods), but you just said "default", which implies that we > could have an opt-out attribute. > > I will say, however, that making NS_REQUIRES_SUPER the default for > overridable methods is

Re: [swift-evolution] Final by default for classes and methods

> - 'private' and 'internal' methods are not exposed outside of a library, so > you can't call them, much less override them. Similar for 'private' and > 'internal' classes: you cannot subclass them. really important point — and imho one of the best arguments not to make final the default: It

Re: [swift-evolution] Lambda function syntax

> am open to whether the introducing keyword is “func” (overloading the > existing keyword but in an evidently separate context, and unambiguously I > believe) – or “lambda” (like Python), or “\” (like Haskell) – or even > something like “cl” (for Closure). The cool thing with Swift compared

Re: [swift-evolution] Fwd: [Pitch] Single-quotes for Character literals

> I suggest reinstating the C convention of using single-quotes for delimiting > Characters. I rarely use chars, but from a theoretical standpoint, I'm not so happy with the ambiguity as well… But one suggestion if you want to make a proposal: Char has a fixed length (well, at least that was

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

> let color : Color? = getFavoriteColor() > if color != nil { > // Color is no longer an Optional > } well, I'd just write if let color = getFavoriteColor() {… This even more as the other solutions hide that "color" isn't the original "color" anymore inside the braces: The first one was an

Re: [swift-evolution] Lambda function syntax

> love trailing closures I wouldn't go that far and just say "})" looks ugly — but that has the same implications ;-) With parameters, trailing closures loose a lot of their appeal, and an alternative syntax ("func(x: Int) {" instead of "{ x: Int in}" isn't that bad for trailing closure

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> I did see that point made earlier in the thread, but I’m not convinced that > design for googleability is the right ordering of priorities. +1 Choosing cryptic names because it's easier to find information about them is bad. With this argument, you can not only fight against removal of the

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> Why would you have an immutable instance member that is always going to have > a constant value of 1? That just wastes space by duplicating the constant > value in many instances. However it is quite reasonable to have an immutable > instance member that defaults to 1, but may have a

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> In fact why not just use the generics syntax with protocols ? Anybody > implementing a "Generic" Protocol has to specify the types. That's a simple solution, but inconvenient: One use case for placeholders (I don't use the official name here to propagate an alternative ;-) is when you have a

Re: [swift-evolution] "Assume" directive for classes and methods

> I've been reading the discussion in "Final by default for classes and > methods" and although I don't have a strong position towards what the default > behaviour should be, I think a directive to change that behaviour should be > added as when nullability was introduced into Obj-C. > > In

Re: [swift-evolution] Final by default for classes and methods

> The benefits of it far out weight the fears of having it. so what is the practical problem that's solved by final that convinced you? I also would change the list of downsides and put "annoyance" on top — especially for those who don't care for theoretical improvement when they have to pay

Re: [swift-evolution] Final by default for classes and methods

>> "If I don't want to subclass something, I just don't do it — why do I have >> to change the properties of the superclass?" > > Fix-its solve this with a single click. Really? I guess I like this alternate reality — can the Xcode in your universe refactor Swift sources as well? ;-)

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> Sorry if this has been discussed and I missed it, but Scala and Kotlin both > support a compact function-like class declaration syntax for simple "case > classes". Just took some time to read more deeply and would have added a reference to Kotlin on my own — I think their approach of

Re: [swift-evolution] Epic: Typesafe calculations

> I'm planning to write a proposal for automatic forwarding. Something like class delegation in Kotlin? Please hurry, I've no work to distract me for the rest of the year, and extending typealias could be a very quick proposal ;-) ___ swift-evolution

Re: [swift-evolution] Proposal: Expose getter/setters in the same way as regular methods

> Of course, if you’re worried about the performance costs associated with that > extra method call, you might want to include a keyword, such as “observable”, > and only generate the method call(s) if that keyword is on the property. I strongly agree that Swift should have/keep a possibility

[swift-evolution] Fluent syntax (replacing void with a useful default return value)

Hi there, this idea might be quite unconventional, but it is simple and wouldn't break any existing code. Returning void has no use beside telling "there is nothing to return" and makes it impossible to perform method chaining, which drives popular systems like iostream and LINQ (the concept

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> You even have a great keyword to search for, right there. Good point - we are lucky that Apple has so much influence to make "swift" already a useful search term so we don't have to look for "swiftlang" ;-) Still undecided wether this argument is a bad justification for cryptic names in

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> The main reason to use `associated` is because the feature is called an > "associated type". If we're willing to rename the feature to "placeholder > type", then `placeholder` would be a good keyword. good point - maybe it's because I'm no native speaker, but for me "associated type" is just

Re: [swift-evolution] Final by default for classes and methods

> Frankly, I think having `final` in the language at all is a mistake. While I > agree that we should prefer composition to inheritance*, declaring things > final is hubris. The only reasonable use case I've seen is for optimization, > but that smacks of developers serving the compiler rather

Re: [swift-evolution] Failable Initializer Suggestion

> How do you guys think of that? Makes sense. Failable init has its roots in Objective-C, throws is a better fit for Swift — but it is not trivial to change all Cocoa class to throw instead of returning nil (at least in theory — most likely many classes don't have that many reasons for a

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

> method cascades I thought there was some sort of showstopper that ended further discussion for Swift 3 — but seems it wasn't the fault of the archive that I didn't find that reason ;-) I'll use the opportunity to talk about my major motivation to want cascades in Swift: Several years ago, I

Re: [swift-evolution] Final by default for classes and methods

> I can see why you view it this way, but access control and inheritability are > orthogonal. as I understand orthogonal (mathematical background), it is definitely not the case: I can't inherit what I cannot access, so there is one impossible combination of the two attributes. The

Re: [swift-evolution] Final by default for classes and methods

> NS_REQUIRES_SUPER as the default is a bad idea. There's a big difference > between methods where you SHOULD call super and methods where you MUST call > super, and NS_REQUIRES_SUPER is meant for the latter case. The problem with > using it where you simply SHOULD call super is there's

Re: [swift-evolution] Final by default for classes and methods

>> Btw: I wouldn't oppose a proposal to allow changing conventions like this >> (there are at least two other discussions about the best default) on a per >> module/file basis — as long as the "local" effect of the setting isn't >> vital, there shouldn't be a problem with customizing. > I would

Re: [swift-evolution] Final by default for classes and methods

>> 5) Prototyping. This should also not influence the decision about what the >> default is for production code. I would not have a problem with a >> prototyping environment allowing `inheritable` by default (maybe a >> Playground mode?). There could even be a tool that migrates the

Re: [swift-evolution] [Proposal] Property behaviors

Quite complex proposal… guess I'll read it a second time when I'm less tired, but I have already one idea for the feature: > Syntax for accessing the backing property > When I saw the examples, I wondered right away "what if foo has an own property called runcible? How is the type modified to

Re: [swift-evolution] Final by default for classes and methods

> I think it's best to keep this thread focused on classes. We can start a new > thread for methods later if desired. But we should wait until the dust has > settled on the classes conversation IMO. I disagree: The whole thread is not about practical implications but rather about general

Re: [swift-evolution] Lambda function syntax

> I'm completely against replacing '->' by ':' it would make unreadable the > declaration of a function taking a closure as parameter, or returning one > (among other things). That's definitely right: Two different separators only shift the problem by one level, but hopefully it won't become

Re: [swift-evolution] Epic: Typesafe calculations

> Search the archives for `newtype`, which is Haskell's version of this feature Thanks for the hint — searching the archives is more complicated as expected ;-), but afaics there haven't been any opposing statements, and the topic just died away without a formal proposal. Any interest reviving

Re: [swift-evolution] FYI: Apple holiday shutdown

Merry christmas to all pushing Swift forwards (and as well to those who are merely watching)! Thank you for the work you have done, enjoy the free time and don't think about the mess that we amateurs will create here till January ;-) ___

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> "Associated type" is the name of this feature The name of the concept is highly inexpressive, and I guess it's far easier to change the docs than to change the language… ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Review] Require self for accessing instance members

> 2. If we do enforce self, method cascading would mitigate some of the > repetition. If both ideas would be decided in a package, I'd rather have method cascading and required self than none of it - but I really doubt that those who want to enforce self where it is optional would vote for any

Re: [swift-evolution] [Review] Require self for accessing instance members

imho the most valuable vote for mandatory self, just one comment on it > 1) Accessing a property, in a class, is more expensive than accessing a local > variable. The above code would require three message sends and/or vtable > accesses instead of one, if it were not assigning the property to

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

It is an appealing idea on first sight, but it makes the language more complex, and I don't think scoped resources are versatile enough to back justify their inclusion. The defer feature which is already mentioned in the proposal is very similar — and I expect that will not only be the case

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

Have you looked at how this is handled in Kotlin? Imho Jetbrains solution is quite elegant — especially as it also has a natural answer to another problem ("flexible memberwise initialization"; the whole init process is only a short chapter in the docs). Of course, their approach is different,

Re: [swift-evolution] Epic: Typesafe calculations

> Yes, care needs to be taken about the associativity and commutativity of > multiplication of units, but that's not too hard either, it basically amounts > to some pattern matching along with symbolic computations respecting > algebraic identities (think of it as a compile-time "unit

Re: [swift-evolution] [proposal] Allow function argument type to be omitted when passing a default value from which it can be inferred

If seen several suggestions to extend inference now, and although it is convenient, it can make it harder to understand what's happening. Imho it would be possible to combine the benefits of both ways without their disadvantages: Xcode already has the ability to correct some errors and warnings,

Re: [swift-evolution] [Proposal] Protected Access Level

> > I can't reply directly to all the points in this thread, but I will just say > that there are ways of emulating protected in the language as it exists today: > > If the goal is to have functions that can be overridden by subclasses without > being called by external classes, you can create

Re: [swift-evolution] [Proposal] Protected Access Level

> Couldn’t you use the same reasoning to claim there shouldn’t be access > control at all? Just add documention on methods you want to mark private > telling users of the library not to call them! I guess you are making fun, but actually, good old Objective-C messaging works just that way: You

Re: [swift-evolution] [Proposal] Protected Access Level

> The purpose of access control isn’t really to keep out malicious users, > though, it’s to prevent accidental misuse and clarify the interface. mh, I would call this a "documenting intend" ;-) > One nice vector for accidental misuse is autocomplete. Even if > layoutSubviews() has a great big

Re: [swift-evolution] [Proposal] Protected Access Level

I'm not opposed to the idea of finer-grained access levels in general, but if the current system is extended, the change imho should be more "holistic": Right now, class hierarchy has no effect on accessibility, and it feels odd to have access level that is different from the others. Doing so

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> • What is your evaluation of the proposal? -1 This clearly makes me part of a small minority, but I doubt that the participants of this discussion are representative for all current and future users of Swift: Those who enjoy tinkering with the design of languages naturally strive for a

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I agree that the current "private" is useful, and would rather keep everything as-is than remove this scope. I'm neutral on adding a new access level, but don't like the "private(file)"-syntax: The issues with properties could be solved (my preference would be "private (set) var x: Int"), but

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> Perhaps we could add some kind of attribute to the type itself to allow for > selection between the two behaviours? imho that's a good direction — it's a pity that linking to other posts is so tedious ;-): I voted for something similar (change the setting for a whole module).

Re: [swift-evolution] SE-0047

I don't think that counting discardable results in existing Cocoas libraries is a good metric for the usefulness of warn-unused-result: Other libraries may follow a different style, and Objective-C is a very bad fit for fluent interfaces. So far, I haven't seen any real world examples of

Re: [swift-evolution] Shortcut for creating arrays

I would create a computed property on String and call it "words" Tino ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Just had an idea for a different approach for access levels (as if things aren't complicated enough ;-) - but I'm only brainstorming here): The problem of access levels isn't limited to programming — file systems have to deal with it as well. So, ignoring ACLs for a moment, imagine protected x:

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

> Can't quite see where "Inheritance for structs / "newtype"-feature" > enables this, however. Care to explain? It's not required, but unless you want to implement a completely new numeric type (like fractions), it is tedious to declare all operations and conversions that are useful or

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

Imho the syntax of the deprecated for-loop was no good fit for Swift, but I've read several rumors about inferior performance of the alternatives…. so, as a basis for further discussion, I'd like to see some reliable numbers: I expect that every loop can be expressed in Swift 3 with identical

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

I encountered the same issues and agree that it can be tedious to deal with enums. Imho the first variant (skipping the switch(self) {} doesn't offer enough benefit to justify a special case. The second is nice because it keeps the "properties" of each case together — but afaics, Swift doesn't

Re: [swift-evolution] struct subtyping

> Could we accomplish something similar to `newtype` by making the `typealias` > declaration more powerful? It's the first thing I tried, but afair someone from the Core Team opposed extending typealias - and I had to agree that an "alias" should be just a synonym.

Re: [swift-evolution] ++ and --

> I think that ++ and — should stay and MUST be implemented as faster > operations than += and -=. If there is an easy way to make operations faster, imho that should be applied to every method ;-) Jokes apart, compilers of today know some really smart tricks, so if "+= 1" is slower than

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> These are special cases — both file-private and module-private is something > that is fairly unusual afaics this is the third time someone mentions that "file-private" is uncommon — so I think it's time someone dissents: That statement is at least subjective… right now, "file-private" is one

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

A more sophisticated rights system isn't necessary, but actually, we could build everything with nothing but "public", so it is always a compromise between simplicity and expressiveness… Imho it would be nice to be able to mark a method that is only there to be overridden and should never be

Re: [swift-evolution] Crypto routines as part of the core library

> This seems like a great candidate for a library that could be developed in > the community and then possibly brought into Corelibs in a future version true — but sadly, there seems to be either no interest or manpower for a boost-like infrastructure… Like many other fundamental topics, I don't

Re: [swift-evolution] [Discussion] Enforce argument labels on tuples

> Do you think it might be possible to add some optional extra flag to the > language to enforce argument labeling. Not only for tuples as I started the > discussion with but also for argument labels on blocks/closures? I'm quite skeptical when it comes to enforce behavior (unless it's the way

Re: [swift-evolution] [Pitch] Richer function identifiers, simpler function types

Although SE-0021 has a good goal, I don't like the details due to the use of parenthesis: I'd prefer to keep them limited to actual function calls. But most of the time, it would be possible to avoid

Re: [swift-evolution] SE-0066 Reaction

> What I’m trying to say is that there are a lot of reasons that the Swift > type system works the way it does (e.g. inout has very specific behavior that > doesn’t work when partially applied, we have specific promotion rules that > apply only in argument lists etc). These reasons and

Re: [swift-evolution] RFC: didset and willset

> didSet and willSet remain outliers in the general rule of conjoined lowercase > keywords. Is there any support for bringing these outliers into the fold? I would rather like to see them disappear completely — although those "decorators" [is there any established term to describe them?] can be

Re: [swift-evolution] RFC: didset and willset

Because some posts explicitly stated the willSet/didSet-functionality should be kept (and I mentioned the option of discarding them): My statement had the same background as Brent's — I expect there will be a "cleaner" and more versatile replacement in the future, so "don't fix it if it isn't

Re: [swift-evolution] Could enums have their rawValue type inferred?

I'm not sure if I want the proposal to be standard-behavior, but in the past, I have written numerous extensions which basically took an enum to forward its raw value to an existing method (mostly keys for NSUserDefaults). So, it would be convenient if the conversation happens automatically… but

[swift-evolution] SE-0084 spinoff: Newlines as item separators

[Due to popular demand ;-) in the discussion of SE-0084: Allow trailing commas in parameter lists and tuples] The option to skip semicolons for statements followed by a newline is only a tiny convinience, yet it is one of the most favored differences to C (and one of the most annoying things

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

hi there, just skimmed through the bigger part of this thread — it's a really interesting discussion, but wouldn't it be worth a topic on its own? The title of this message addresses a much simpler question (that imho still deserves some answers ;-) Tino

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> func f(obj: A) {..} > if obj is A {...} > obj2 = obj as! A > > (but I still don't understand real use case of things like (String | Int)) Ceylon has already been mentioned: It uses the concept for its optionals. Swift uses enums, and those could be made obsolete by union types.

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

>> Would you then recommend removing trailing comma support for collections on >> the same principle? me too — so, for the review-part: -0.5, no trailing commas (it's not a full -1 as long as I'm not forced to add those trailing commas) I don't think they are convenient, and even if that is

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

> Tino, would you like to form an 'official' proposal for this(newlines as > separators) feature? As I can see, there is a much support in community for > this idea, but no one said yet he/she will create a proposal for this.(or I > just missed this) I feel honored, but I guess there are

Re: [swift-evolution] Union instead of Optional

I don't know if there has been any internal discussion about using union-types instead of enums, but afaics, there are no obvious downsides for that approach. > I'm a little curious as to why union types keep on coming up, when enums can > do everything they can and much more (methods,

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

I have seen wrong usage of bool values in Objective-C many times, and although most of those weren't real problems, I'd rather prefer to be forced to use a single pair of words for true/false. If this single pair is true/false or yes/no (or even .yes/.no [enum]) isn't that important to me, so

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

I've been thinking of a different name as well — but I was concerned by the fact that "class" is lowercase, while all "regular" types start uppercase… I'd prefer "Class" or "Reference" over "reference". Tino ___ swift-evolution mailing list

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

> The question is whether the downside to variadic parameters is really enough > to justify _removing_ an existing language feature. > > The burden of justification should be on those people wanting to change the > language, not on those wanting to maintain the status quo and “I don’t like >

Re: [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types

+1 It's not breaking anything, it's a useful feature, and I think it adds consistency: I already encountered situations where I tried to use "Self" in contexts where it is not available now. Tino ___ swift-evolution mailing list

Re: [swift-evolution] [Pitch] Unifying init parameters with properties

There has been a long debate about something similar: [Proposal Draft] Flexible memberwise initialization Afair there has been a general agreement that the current boilerplate is ugly, but all suggested alternatives had flaws as

Re: [swift-evolution] What about a VBA style with Statement?

> (in Smalltalk, like in Swift?, if i remember correctly, ‘self’ is implicitly > returned in absence of a return value and can be ignored. I'm a big fan of returning self — its much more useful than void… But it seems the Swift-community doesn't like method chaining.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0098: Lowercase didSet and willSet for more consistent keyword casing

-1 > I'm not sure this intermediate churn is really worth it. That has been my opinion in the original thread, and I haven't read anything that changed my mind: Better live with a tiny inconsistency now than deal with three different forms of didSet/willSet in the future.

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

I have the feeling that there's to much stress right now to handle this pitch in the way it deserves… it might be better to do the split, but imho there is no obvious syntax for protocol conformance, so I expect a long discussion on the details. Depending on how important protocols will become

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Thanks for the detailed answer — I didn't expect it. I'll re-order the original message, since you had a genuine question (to bad for me if it was just a rhetorical one :) whose answer might be more interesting than the pointless remarks afterwards ;-) > If you were writing a library, what

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

>> Safety is valued, but Swift cares (and should care!) about pragmatism as >> well… the most obvious example that comes to my mind are arrays, which have >> no safeguards that stop you from accessing elements that aren't there. > > I'm not sure I understand this point. First, a guaranteed

Re: [swift-evolution] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

I share the minor concerns that have been expressed so far. My first thought on this topic ("MyStruct.size") had a obvious flaw, but I wouldn't fear name collisions with something like "MyStruct.memoryLayout.size". This one most likely has issues as well, but imho they aren't that obvious and

Re: [swift-evolution] executing a string

Turning strings into selectors is a powerful feature as well ;-) — but afaik, Swift doesn't use another sort of special dispatch besides what is known from other languages. ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

> Am 15.07.2016 um 23:56 schrieb Dave Abrahams via swift-evolution > : > > We're trying to get away from “magic” properties that exist on every > type, I think. I've a serious aversion against regular-looking constructs with special power as well (from time to time,

[swift-evolution] Getting rid of "..." in variadic functions

Just wanted to ask about the current status — but then saw that there has been a PR already… It's a pity that there hasn't been the time for a detailed answer, as I still think this is one of the best non-trivial proposals so far. So, I guess you're discouraged by the backfire, but afaics,

Re: [swift-evolution] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> Given that this was probably the most polarising proposal ever, I am very > impressed with the patience and professionalism the core team has shown in > handling the situation and ultimately converging on an elegant solution … and at first sight, they even found a way to please opposers of

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

I'm not sure wether the review period is actually over (or better say "turned into an internal discussion", as I haven't seen a result yet ;-), but as nobody jumped onto the "something more holistic"-train, I used my free time at the lake for some thinking… There are three degrees of freedom,

Re: [swift-evolution] [Proposal] Variadics as Attribute

> Am 21.07.2016 um 22:11 schrieb Haravikk : > > it also opens passing of arrays to variadic functions, which seems to be > fairly desired despite no proposal that I could find I haven't seen a complete proposal, but I managed to remember a link to the last(?)

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> Am 22.07.2016 um 00:29 schrieb Garth Snyder via swift-evolution > : > > In the original proposal (and the ensuing discussion), there was tacit > agreement that subclassability/overridability and access levels should be > orthogonal. However, given the direction

Re: [swift-evolution] [Idea] Specialising based on function parameter values

Hi Karl, I started a discussion about such a concept (afair under the label "compile-time parameters"), and "completing generics" talks about it as well. Although I think it is quite fundamental (Swift has no arrays of fixed size(!)), and shouldn't be that hard to implement, I'm not sure if it

Re: [swift-evolution] [META] Gmane and Swift Evolution

I think this news is worth to be linked to the thread "[swift-evolution] [Swift4] Mailing list vs. Forum" — but there's just no good way to do so ;-)___ swift-evolution mailing list swift-evolution@swift.org

  1   2   3   4   >