[TL;DR]
SE-0033 ports objective-c global strings to swift enums, but the reverse
seems to be missing. There should be a swift construct that can be
accessible by objective-c.
[Proposal]
In a previously implemented swift proposal, the concept of NS_STRING_ENUM
and NS_EXTENSIBLE_STRING_ENUM was born
You could try awakeFromNib which is called when interface builder creates
the view.
But if you are instantiating it programmatically, the closest thing would
be drawRect. It calls multiple times so you may need to add logic to ensure
that it only happens once.
I think a "didFinishInitialing" met
Alexander, I took your code and "flattened" it with what currently exists
in Swift 3. Is this not flat enough for you?
struct A {
var a = 0
}
extension A {
struct B {
var b = "Bee"
}
}
extension A.B {
struct C {
var c = 0
func someFunc() {
print("something")
}
Does anyone have any thoughts on this idea?
I Made a draft proposal of this very idea
https://github.com/wh1pch81n/swift-evolution/blob/master/proposals/-Swift-enum-strings-ported-to-Objective-c
On Sat, Nov 19, 2016 at 2:44 PM Derrick Ho wrote:
> [TL;DR]
> SE-0033 ports objective-c global s
No problem Alexander!
On Sun, Nov 20, 2016 at 1:15 PM Alexander Doloz
wrote:
> Frankly speaking I didn’t know it’s possible with extensions :) Thank you
> for answer, it will be helpful for my project.
> Since this method works my proposal no longer makes much sense.
>
> 20 нояб. 2016 г., в 21:0
Actually this is very consistent. You can not nest data structures like
enums, structs, or classes in a protocol. This is because a protocol is
meant to be a list of variables and functions that data structures may
conform to. A protocol is not a data structure.
On Mon, Nov 21, 2016 at 7:33 AM Jaku
Jakub, try this...
struct WorkingEngine {
enum States {
case idle
}
}
Then you can call it
WorkingEngine.States.idle
On Mon, Nov 21, 2016 at 9:56 AM Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:
> Proposal is being worked on.
> https://github.com/apple/swift-evolution/pull
If you want to feed it a type rather than infer it from variable type or cast
it using as! Then you can just add the type as a parameter…
func processAll(type: T.Type, in vehicles: [Vehicle], condition:
(Vehicle) -> Bool) -> [T] {
return []
}
processAll(type: Bicycle.self, in:
I think enum strings should gain better interoperability with swift.
Something like this: enum City: String { case NewYork = "New York" }
This can be ported over to Objective-c like this: typedef NSString * City;
static City const City_NewYork = @"New York";
I don't think the angle brackets adds any additional benefit than adding
the type information as a parameter. Adding Angle brackets will just make
it more crowdedplus, the syntax just seems too much like c++
On Tue, Nov 29, 2016 at 8:43 AM Goffredo Marocchi via swift-evolution <
swift-evolutio
I like the idea of overloading an enum type. The issue happens when we use
it in a switch statements. Currently the parameters can be excluded.
However, We can make it a rule that any overloaded enum requires the full
signature.
On Tue, Nov 29, 2016 at 10:59 AM Adrian Zubarev via swift-evolution <
I like this proposal!
+1
Oldvalue and newvalue have different meanings. I have witnesses programmers
overriding oldvalue with the name newvalue and vice versa.
Of course if you are good at reading the documentation then you would not
make the mistake.
Swift should be a language that prevents a
I feel like inline assembly is a very niche idea. Inline assembly is
supported by c and by extension objective-c.
//file.h
void aCFunction();
//file.m
void aCFunction() {
int a=10, b;
asm ("movl %1, %%eax;
movl %%eax, %0;"
:"=r"(b) /* output */
:"r"(a) /* input */
:"%eax" /* clobbered register */
I believe Erica's point about RIGHT NAMES ONLY is the most clear. While a
block-like syntax using $0 is nice, it fails to communicate whether it is a
newvalue or an oldvalue.
Therefore instead of following a block-like pattern it should follow a
delegate-function like pattern. This would remove th
True, adding the type would be redundant. Here is my revised solution.
Which basically still allows you do use a different name besides
newValue/oldValue
set { let temperature = newValue
// do stuff
}
didSet { let temperature = oldValue
// do stuff
}
On Sun, Dec 4, 2016 at 12:47 AM Saagar Jha v
Does the following expression evaluate to true?
p is AnyObject
If it does then you may have found a bug.
On Sun, Dec 4, 2016 at 9:46 PM Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:
> The following currently does not work:
>
> protocol P: class {}
> class C: P {}
>
> fun
Jay, I fail to see the point you are trying to make. Can you clarify why we
need a new map method for an optional array of elements?
On Tue, Dec 6, 2016 at 9:46 PM Jay Zhao via swift-evolution <
swift-evolution@swift.org> wrote:
It applies in theory to think Optional as a collect of one and for t
If you are confused by what $0 represents then your shouldn't use the short
hand version of writing a block. The long version includes the type which
will remove all mysteries
// What is $0
array.map {
$0.method()
}
// No mystery of $0. It is clearly a String?
array.map { (name: String?) -> Strin
-1 we don't need any more access modifiers. We already have an excessive
amount: 5
On Thu, Dec 8, 2016 at 12:55 PM Jim Malak via swift-evolution <
swift-evolution@swift.org> wrote:
> Hi Tino,
> This is my first use of this forum. I certainly did not mean to cause pain
> for anyone.
> At Gonzalo's
I placed he code you wrote in the proposal in playgrounds and it works
perfectly. (reproduced below). Overloading operators used to only happen
globally and since swift 3 they allowed you to put then inside the
class/struct
public struct NonEmptyArray {
fileprivate var elements: Array
f
You may want to add the specific error to your proposal.
*error: member operator '•|' must have at least one argument of type
'NonEmptyArray'*
*public static func •|(lhs: Element, rhs: [Element]) ->
NonEmptyArray*
On Sat, Dec 10, 2016 at 11:49 PM Derrick Ho wrote:
> I placed he code yo
It bugs me as well that we can not test private components using XCTest.
Objective-c never had this problem since privacy doesn't exist. I would
like to see a version of XCTest that allows us to test every component.
On Mon, Dec 12, 2016 at 12:02 AM Benjamin Spratling via swift-evolution <
swift-
Swift generics are swift only
Objective-c lightweight generics are not true generics but rather just
annotation that helps with interoperability.
Even though you are subclassing a generic class into a supposed non-generic
type it is still a generic. Inheritance follows an is-a relationship and
th
testing which needs to be done.
> >
> > -Ben
> >
> > Sent from my iPhone.
> >
> > On Dec 13, 2016, at 1:35 AM, Jean-Daniel wrote:
> >
> >> An interesting reading about testing private members:
> >>
> >> https://cocoacasts.co
You can currently access swift enums from objective c provided that it is
marked @objc and inherits from Int.
Objectivec can not however access a swift enum that inherits from a string.
I've asked the community about how they feel about enabling this but there
was little to no response.
On Thu, De
Use protocols
{get}
Can be used for let
{get set}
Can be used for var
On Thu, Dec 15, 2016 at 1:16 AM Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:
> Howdy,
> Thanks, I’ll consider this as an alternative.
> I don’t see that this solves the issues of w
let url = URL(string: "https://example.com";)!
let url = #url("https://example.com";)
Are not that different in length. It really isn't saving you much.
I suppose you can try overloading an operator to get something to the
effect you want.
On Fri, Dec 16, 2016 at 6:19 PM Micah Hainline via swift
I suppose if compile time validation is desired I guess we can do something
similar to @ibdesignables. Except instead of live rendering UIViews we
would render the url
Marking a URL like this
@urlvalidation("a URL string")
Would make it fire a compiletime URL request and give a warning if it was
struct Person {
Var name: String = ""
func with(name n: String) -> Person {
var a = self
a.name = name
return a
}
}
let andy = Person().with(name: "Andy")
let brandon = andy.with(name: "Brandon")
On Mon, Dec 19, 2016 at 10:28 AM Andy Chou via swift-evolution <
swift-evolution@swift.org> wrote:
>
That is correct Andy. Let-constant can not be assigned a new value after it
gets its initial value.
It is unclear why you are against turning your properties into var's.
Because you are using structs, all properties are copied by value.
struct Person {
var name: String
}
let andy = Person(name
The core team designed swift blocks to range from concise to verbose. Which
one you use depends on your needs.
If you want to write parenthesis then by all means write parenthesis; no
one is stopping you.
I would rather keep the block syntax as it is so that everyone can choose
the style that mat
Jeremy,
The problem you present is not a mutability problem but rather a cache
design problem. If your hash value truly is expensive then you only want to
calculated it when you need to...
struct Person: Hashable
{
var firstName: String {didSet { _hashValue = nil }}
var lastName: String {
I believe variables under private(set) can still be accessed with KVC (At
least when the class inherits from nsobject.)
On Thu, Dec 22, 2016 at 9:19 AM Andy Chou via swift-evolution <
swift-evolution@swift.org> wrote:
> Point taken. I think Swift supports both styles reasonably well. Initially
> i
Can you not write this?
switch condition {
case 1: do {
//
}
case 2: do {
//
}
}
On Fri, Dec 23, 2016 at 8:35 AM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:
> Hi Marco,
>
> This idea has already been discussed on this list; however,
> source-breaking changes require "extrem
I personally do not see anything wrong with its current placement.
It may be there because it was based on an existing cocoa pattern from
objective-c
- (NSString *)bazWithError:(NSError **)error { ... }
Because objective c could only return one thing, using pointer-to-pointer
was needed to deliv
We need this.
On Mon, Dec 26, 2016 at 11:57 AM thislooksfun via swift-evolution <
swift-evolution@swift.org> wrote:
> (I think this is the right place for this suggestion, but please let me
> know if I'm mistaken)
>
> There is currently no supported way to have some dependencies only used
> for te
I like to imagine "throws -> returnType" like a special tuple
let t = (e: NSError?, r: returnType)
Where "try" is a special function that accepts a tuple argument; a success
closure; and one or more error blocks
func try(
_ t: (e: NSError?, r: returnType)
, do: ()->()
, catch: ((Error)->())...
)
I like the idea of "throw" having information about what might be thrown.
Maybe you have an enum of errors that may be thrown. How would the
programmer know what might get thrown if they don't know the implementation
details?
While adding the throwing info in the comments is good, we might be bet
Daniel Leping, I am unfamiliar with java. Do you have any resources that
describe the nightmare in detail?
On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <2...@gmx.de> wrote:
> -1 for specifying errors for throws. Please don't. Proven by practice in
> java it's a nightmare.
>
> In Java, this topic is r
I suppose "throws" could be enhanced to produce a compiletime enum
func bar() throws {
throw NSError()
throw MyEnumError.firstError
}
Under the hood each expression passed to "throw" could make something like
enum bar_abcdefj_throw {
case genericError // all NSError go here
case MyEnumErrorFirst
Dec 27, 2016 at 1:17 PM Xiaodi Wu wrote:
> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I suppose "throws" could be enhanced to produce a compiletime enum
>
> func bar() throws {
> throw
-1
On Wed, Dec 28, 2016 at 9:37 AM Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:
> –1. I'm not sure there's a reason to draw a line from
> removal-of-tuple-splat to removal-of-tuple-returns, other than the idea
> that they both involve tuples. In a lot of languages, purely
I'm trying to revive an old thread. I'd like to hear from the community.
Can we make a swift enum string interoperable with Objective-C?
Currently NS_STRING_ENUM ports from objective-c to swift but not the other
way around.
I feel that if you can go one direction you should be able to go back.
Anyone on the core team like to say anything?
On Fri, Dec 30, 2016 at 9:15 AM Derrick Ho wrote:
> I'm trying to revive an old thread. I'd like to hear from the community.
>
> Can we make a swift enum string interoperable with Objective-C?
>
> Currently NS_STRING_ENUM ports from objective-c to swi
In your first example the switch statement is evaluating whether the given
tuple of type (_:bool, _:bool) matches another tuple of type (_: bool, y:
bool)
The type signature doesn't match.
I believe the change would not be additive like you say because it seems
like it would require a change in h
John McCall +1
I agree. The placement should remain the same.
On Tue, Jan 3, 2017 at 8:29 AM John McCall via swift-evolution <
swift-evolution@swift.org> wrote:
> On Dec 29, 2016, at 12:33 AM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Wed Dec 28 2016, Chris L
-C to Swift. Could we find a way to unify them?
>
> On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm trying to revive an old thread. I'd like to hear from the community.
>
> Can we make a swift enum string
So could we add a @trailing or @nontrailing to the block argument to toggle
on and off the feature?
On Wed, Jan 4, 2017 at 8:35 PM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:
>
> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution <
> swift-evolution@swift.org>
from Obj-C to Swift. Could we find a way to unify them?
On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution <
swift-evolution@swift.org> wrote:
I'm trying to revive an old thread. I'd like to hear from the community.
Can we make a swift enum string interoperable with Obje
f the core team, of course, but I like this change in
> principle.
>
> My one concern in this case would be choosing a naming convention for the
> back port that makes sense both ways. The naming convention you propose (
> EnumName_EnumCase) seems inconsistent with the current impor
+1️⃣ for unsafecompilable
On Fri, Jan 6, 2017 at 6:22 PM Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:
>
>
> -Ben
>
> Sent from my iPhone.
>
> > On Jan 6, 2017, at 5:15 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I wouldn’t be ho
Don't remove tuples.
They make it very convenient to pass multiple values around.
Tuples use .0 instead of [0] which prevents any index out of bounds issues
at compile time rather than at run time.
Tuples should not adopt a dictionary style access because dictionaries
imply nil for any key that d
I think pattern matching is the most compelling reason to keep tuples.
If they were gone, how would we replace the following?
switch (a, b) {
case (value1, value2):
case (value3, value4):
}
On Sun, Jan 8, 2017 at 2:31 AM Derrick Ho wrote:
> Don't remove tuples.
> They make it very convenient to
Correct me if I am wrong but currently there are only two ways to extract
the value of an associated type.
// 1
switch n {
case foo(let value):
print(value)
}
// 2
if case foo(let value) = n {
print(value)
}
I think it would be nice to have another way. Maybe a tuple-like pattern.
let value = n
On Jan 7, 2017, at 23:37, Derrick Ho wrote:
I think pattern matching is the most compelling reason to keep tuples.
If they were gone, how would we replace the following?
switch (a, b) {
case (value1, value2):
case (value3, value4):
}
I really have to ask. What do you use this for? In
Currently we can write a helper method to aid in getting the values inside
the enum associated value. Below is a fully working implementation:
```
enum Package {
case box(String, Int)
case circular(String)
var associated: Associated {
return Associated(package: self)
}
struct Associated {
*if let *is fine the way it currently is. It may be strange to newcomers
since it is unique, but once you get used to it, it is super useful.
On Sun, Jan 8, 2017 at 7:58 AM Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:
> I quite really like the `if let` syntax, fee
Its probably better to use a Boolean variable close_file to "cancel" it,
rather than change the entire language.
func openFile(kind: String) -> UnsafeMutablePointer? {
var file = fopen("MyFile.txt", "r")
var close_file = true
defer { if close_file { fclose(file) }} // <--
if file
Thanks Chris! Thanks to yours work we got an improved objc and swift.
On Wed, Jan 11, 2017 at 4:33 AM Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:
> Good news for Chris and Ted, I guess, congrats guys :)
>
> I am wondering, what’s the future of Playgrounds, now that
Interesting proposal Tim. So instead of repeating the enum cases multiple
times we repeat the functions multiple times?
I feel like this merely flipping the complexity but not really getting rid
of it.
On Tue, Jan 10, 2017 at 8:08 PM Tim Shadel via swift-evolution <
swift-evolution@swift.org> wrot
Have fun working at Tesla Mr Chris Lattner!
I look forward to seeing tesla car apps that can be written in swift.
On Wed, Jan 11, 2017 at 1:22 PM Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:
>
> > On 11 Jan 2017, at 18:18, John Pratt via swift-evolution <
> swift-evolution@
I think it is better to create a syntax for getting the associated values
and then comparing them.
enum Option {
case foo(String)
case bar(Int)
case zip
}
let op = Option.foo("hello")
let bb = Option.foo("world")
// proposed tuple-like syntax
op.foo.0 // returns Optional("hello")
// then we ca
enum Something: RawRepresentable {
}
Generics?
On Mon, Jan 16, 2017 at 1:51 PM Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:
> This idea by Karl made me branch off a new thread.
>
> 2017-01-16 21:28 GMT+03:00 Karl Wagner :
>
> It would be helpful for synthesised RawRep con
It probably is a good idea.
Perhaps the changes can be done in the Package.swift file but allow nesting
of dependencies.
Suppose your dependency is like this where P is your current project
P --> A --> B
Normally P we would describe its dependency on A while B would be
abstracted away. In A, th
-1
On Wed, Jan 25, 2017 at 1:11 PM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:
>
> > On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch
> wrote:
> >
> > Really? My observation from a quick test is that "a? = b" assigns b to a
> if a already has a value, or does nothing if it'
I don't like mailing lists since it is very easy to forget about a topic.
What I noticed about mailing lists is that the most controversial topics
live the longest. I think swift-evolution should be able discussing the
stuff that matters for the future of swift.
I think the best choice for that wo
I'm surprised there is so little support for JIRA. Anyone think it's a bad
tool for the job?
On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via swift-evolution
wrote:
> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I haven't y
Boris,
My Intent is to make it easier to develop dependency B. I may want to
develop on a feature branch for dependency B so I'd like to use PM to force
that to happen.
I don't want to have to cd into the A folder and then cd into B to make
that change. I want to control the whole thing from the
The answer is simple, it becomes ambiguous about whether it should get the
var or the function pointer
Suppose we could do this
let r = 5
func r() {}
If we call r, should we get 5 or should we get ()->()
On Mon, Jan 30, 2017 at 4:21 PM Sean Heber via swift-evolution <
swift-evolution@swift.org
If you make a dynamic framework called APIFramework
And add a public class called URL_ME
You can instantiate it with APIFramework.URL_ME() from your project.
I haven't tried to see if this would work with global variables but I
assume it would.
On Mon, Jan 30, 2017 at 3:09 PM Robert Widmann via
ion@swift.org> wrote:
> +1 for either e-mail or GitHub issues. No need for yet another tool...
>
> R+
>
> On 28 Jan 2017, at 01:21, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolut
Maybe we can add a new parameter "otherwise" to the forEach method
[1,2,3,4].forEach({
// do something
}
, otherwise: {
// do something if it is an empty array
})
On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:
> I'm of two minds on this feature; I
Shouldn't NSUInteger always become UInt in swift?
On Thu, Feb 2, 2017 at 12:07 AM Freak Show via swift-evolution <
swift-evolution@swift.org> wrote:
> I have a framework I wrote that maps Objective C objects to sqlite records
> - deriving sqlite schema definitions from property definitions. You s
I feel like warnings showing up as you type are an IDE's responsibility.
Annotations to delay warnings seem like noise. Once you get used to
programming you don't need the annotations.
If warnings are bothersome, then turn it off in the Xcode settings!
On Thu, Feb 2, 2017 at 1:34 PM Pierre M
I agree with you on point number two. There is way too much scrolling. Im
viewing it on mobile so that's even more scrolling. Discourse allows
jumping to the next topic so if I don't want to scroll I can jump to the
next topic.
On Sat, Feb 4, 2017 at 2:36 PM Cihat Gündüz via swift-evolution <
swift
If the \ operator is not defined in swift, does it treat it as something
that can be operator overloaded?
On Sun, Feb 5, 2017 at 10:29 AM Nicolas Fezans via swift-evolution <
swift-evolution@swift.org> wrote:
> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
I don't like the idea of for-else since it doesn't really add much value.
It hardly saves you any typing.
-1
On Mon, Feb 6, 2017 at 6:26 PM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:
>
> On Feb 6, 2017, at 11:06 AM, Jordan Rose via swift-evolution <
> swift-evolution@swif
I have found it strange that operator characters are the only ones that may
be used as operators. Sometimes Characters that look like operators are not.
Why does there need to be a divide?
Why can't an arbitrary set of characters become operator-ized?
For example some people would like "and" to
-1
I prefer to have enums enforce that all cases are met otherwise use a
default value.
If an API changes and adds new cases I want to know about it so that I can
do something about it! If we hide it then weird and mysterious bugs might
creep up
On Tue, Feb 7, 2017 at 4:22 PM Tanner Nelson via sw
If you use the "swiftc" command it will create an executable. Maybe there
is a command in there to create linker files which you can offer to your c
project.
Any one on this threat super knowledgeable on the "swiftc" command?
On Thu, Feb 9, 2017 at 1:53 AM Zheng Ping via swift-evolution <
swift-ev
Just for the sake of completeness... :)
open open(set) var open_open = ""i
open public(set) var open_public = ""
open internal(set) var open_internal = ""
open fileprivate(set) var open_fileprivate = ""
open private(set) var open_private = ""
public public(set) var public_public = ""
public intern
let test: [Int]? = nil
for b in test ?? [] where b != 42 {
Print(b)
}
I don't think you need new syntax since what you want can be accomplished
quite succinctly already
On Sat, Feb 11, 2017 at 8:18 AM Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:
for i in test ?? [] {
I find the final keyword useful when I want to communicate that this class
should not be subclassed.
I think the behavior should remain the same since it is useful.
On Sun, Feb 12, 2017 at 5:15 PM Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:
> On Feb 12, 2017, at 3:52
I think I we can live with the original three: public, internal, and private
Where public is visible to all,
Internal is visible to all within the module, and private is visible only
to the class and the same file.
We can still fulfill the same roles that the current five fill.
Open can become p
There is no need to change it
Since the context basically disambiguates the meaning of !
The next best thing is to compare it to false
(val == false) // same as !val
On Wed, Feb 15, 2017 at 3:02 PM David Waite via swift-evolution <
swift-evolution@swift.org> wrote:
> If someone came with a nice
I agree that the current state of bug reporting through radars is
unmotivating.
We file these bug reports and have no idea if it even made a difference.
After seeing this many times we just don't bother with bug reports.
Sure I understand that internally apple uses duplicated issues to show how
o
What wrong with [unowned self]
On Sat, Feb 18, 2017 at 11:01 PM Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:
> This reminded me of an idea I had long time ago which will have a similar
> effect: add a way to disable implicit captures for closures. FWIW.
>
> > On Feb 18, 2017
The first time I read through the swift manual. I thought to myself, "swift
is Apples version of C++"
The book on c -- the C programming language by Brian kernighan -- is around
200 pages.
As for objective c I've yet to see a book that covers more than a single
chapter Before diving into cocoa fr
Swift should not forsake objective-c. At least not when it comes enum
strings. Although swift enums are suppose to be swift only, I think we
should add a new attribute to slightly relax that. I think a good
attribute would be @objcstring.
By adding @objcstring, an objective-c exclusive class wi
nst in objc should be allowed the same treatment.
> Though the only other type that comes to mind is float/double.
>
> On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift should not forsake objective-c. At least not whe
o = 1,
> IntEnumBar = 2
> };
>
> // Proposed (static or extern, depending on implementation)
> NSString *const StrEnumFoo = @“foo";
> NSString *const StrEnumBar = @“baz";
>
> In fact, I’d go a step further and say any RawRepresentable enum as a
> globally init
I've thought about how to deal with override in a way that is consistent
with the language. Maybe something like this?
// publicly visible but can't be subclassed.
public private(subclass)
// publicly visible and may be subclasses within the module. The default
public internal(subclass)
// publi
Oh, I thought this would be another discussion about namespaces.
On Mon, Feb 20, 2017 at 8:39 PM Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:
> > On Feb 20, 2017, at 5:36 PM, Brent Royal-Gordon
> wrote:
> >
> > Okay, lots of people want to have some kind of submodule
introduce a feature
> so that static members that are layout-compatible with String are bridged
> as global strings with the supplied name.
>
>
>
>
> On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift shou
I've read the pitch, but it isn't clear what the ask is or what benefit it
would give.
On Wed, Feb 22, 2017 at 8:05 AM Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:
>
> On 22 Feb 2017, at 11:48, Brent Royal-Gordon
> wrote:
>
> On Feb 22, 2017, at 3:32 AM, Haravikk via swift-evo
foo(_) seems better. A colon would imply there is an argument of which
there is none.
On Wed, Feb 22, 2017 at 4:52 AM Patrick Pijnappel via swift-evolution <
swift-evolution@swift.org> wrote:
> I'm personally in favor of foo(_), as the number of colons currently
> lines up directly with the number
Argument labels on blocks arguments should be brought back.
On Wed, Feb 22, 2017 at 4:26 AM Franklin Schrans via swift-evolution <
swift-evolution@swift.org> wrote:
> I don’t see why it should be available in function arguments.
>
> The separation of the type and its label makes sense semantical
Did you know you can use a static variable as a default parameter?
class poncho {
static var color= "yellow"
func foo(color: String = poncho.color){}
}
I think instance members should not be allowed as default members though.
It may lead to unexpected behavior.
On Wed, Feb 22, 2017 at 11:06 PM T
The back tick option is interesting. Back tick means "don't treat this as
an expression" which allows us to use keywords in certain areas but have
them. Act as something that isn't a keyword.
let f = `foo()`
However looking at it like this it almost looks like a string.
On Thu, Feb 23, 2017 at 9:
Does swift still use #?
foo(#)
It might be more obvious then
foo(_)
People might mistake it for foo(_:) if they are just glancing at it.
But foo(#) looks special.
On Thu, Feb 23, 2017 at 1:07 PM Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:
> FWIW, I do think the foo(_) i
1 - 100 of 118 matches
Mail list logo
