In addition to being unspecific, how would you access an optional closure?
Since trailing operators can’t be separated with whitespace, how do you
differentiate two trailing “?” from a “??” operator?
i.e.
let a:Int? = ...
let b:Int? = ...
let someFunction:((Int, Int)->(Int))? = ...
let c = so
Sound great!
Last week I started working on a pure-swift graphics library, one goal being
fast server-side graphics manipulations, and already have .png decode/encode,
and quadratic bezier curve stroking implemented, slowly, and poorly. I’m
working on TrueType fonts right now, and intend to
Howdy,
It’s good to have a formal, language supported way to manage these aspects of
concurrency.
In particular, I like that it establishes the asynchronously provided values
into the surrounding scope, like guard. This helps me write a clean sequence
of calls with access to values which ‘ski
It prevents accidental infinite loops of inits, which is possible in Obj-C.
> On Jul 26, 2017, at 12:36 AM, Daryle Walker via swift-evolution
> wrote:
>
> [Sorry if this's been discussed before.]
>
> As long as the superclass sub-object gets initialized, it shouldn't matter if
> the initializ
> On Jul 12, 2017, at 7:33 PM, Itai Ferber via swift-evolution
> wrote:
> When the conditional conformance feature arrives in a future Swift release,
Speaking of this, what concerns me is the really long list of approved swift
features that haven’t been implemented. We had a bunch of features
> On Jul 8, 2017, at 4:08 PM, Christopher Kornher wrote:
>
> I am opposed to this proposal because it muddies up the language to support
> what is essentially an edge case. The standard way to exit a function early
> because an exception is thrown is to make the function itself throw, if it is
> func doSomething() throws → Result? { … }
>
> How would you handle both the catch and the let binding of the result?
I agree this proposal needs to define the behavior, since returning an optional
from a throwing function is valid.
I see a few options:
1) find a way to generally incorporate
Often I want to separate my data model into a separate framework from my UI.
This enables separation of data and logic tests from UI tests. And sharing a
common data model between multiple apps, such as a end-user facing app and a
back-of-house app.
I also like to use structs to support simpl
Howdy,
I love it! The “do" blocks never did “feel” like Swift. I can see how
both would be useful.
I like to use as many conditionals in a single guard statement as I can
get away with, so I was concerned that guard/catch would need to interoperate
with guard/else. However, I
> On Jun 24, 2017, at 6:24 PM, Anders wrote:
>
> The feature you called for is generalized existentials. It is on the Generic
> Manifesto and had a few long discussion threads on the list before.
> Apparently, it is out of scope for Swift 4, and whether it is in scope of
> Swift 5 remains to
I’m running into trouble using protocols as types when they have an associated
type. I understand the restriction of using a protocol with an associated type
only as a generic constraint, since our down-casting syntax has no way of
checking the associated types. However, if I’m considering whe
I notice the BinaryInteger's func word(at n: Int) -> UInt function expects a
2's complement representation. Do you expect that "BigInt" will be implemented
with 2's complement? As a nonmutating function, I would think any
implementation from a 1's complement big int would result in O(n^2) unl
-Ben
Sent from my iPhone.
> On Jan 6, 2017, at 5:15 PM, David Sweeris via swift-evolution
> wrote:
>
> I wouldn’t be horribly opposed to adding a function called “willItToCompile”,
> “compileAnyway”, “noSrslyIDontCare”, or some other equally explicit name,
> simply because that way it’d be
Howdy,
Yes, I was also intrigued by the “Regex” validation mentioned in
another post. It could offer a convenient way to get some literals support in
without the headaches associated with the constexpr C++ approach.
I’m curious, though, how many types can we image in can be valid
Howdy,
I'm definitely on the "no force unwrapping bandwagon". And I also see a
huge difference in force-unwrapping a value derived from a literal, which can
be unit tested, and force-unwrapping a value determined at run time, which
might fail validation. That's where I draw the line.
I ha
Howdy,
Do you see this working with the package manager as well?
-Ben
> On Dec 14, 2016, at 7:42 AM, Jeremy Pereira
> wrote:
>
> The Swift compiler can give you the information that you want.
>
> Here is what you can do:
>
> Write a Swift source file that creates an instance of the t
Howdy,
Thanks, I’ll consider this as an alternative.
I don’t see that this solves the issues of whether a property on a
class is let, however.
-Ben
> On Dec 14, 2016, at 11:41 PM, Derrick Ho wrote:
>
> You might be able to ensure access modifiers by using protocols.
>
> If you
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
>>> wrote:
>>> Howdy,
>>> I’d like to see how much interest there is fo
> On Dec 12, 2016, at 2:17 AM, Rien wrote:
> That is a very elusive goal.
> The best way to do this is through hiring competent people…
If nothing else, I would hope that we can agree that enabling the testing of
all our design choices is a goal.
Towards that, my goal here is falsifiability, t
-Ben
Sent from my iPhone.
> On Dec 11, 2016, at 11:43 PM, Brian Gesiak wrote:
> Maybe your goal is to ensure that other programmers don't accidentally change
> the accessibility levels. Again, I think because they're straightforward, I
> don't think there's much danger there.
>
> To me, te
Howdy,
I’d like to see how much interest there is for adding these to the
XCTest module. If I have missed some pro or con, or missed a technical point,
your feedback is welcome before I go to the lengths to draw up a formal
proposal.
There are several features of Swift which cannot be
Howdy,
I would appreciate it if someone with a working knowledge of the
.swiftmodule format and especially the DECLS_AND_TYPES_BLOCK block would
contact me privately.
I’m working on a module which extracts information from .swiftmodule
files (the binary files, not the directories
9:36 AM, Jeremy Pereira
> wrote:
>
>
>> On 2 Dec 2016, at 14:07, Benjamin Spratling via swift-evolution
>> wrote:
>>
>> I agree that there is a major problem with “subclasses must override these
>> methods”. We have no capability to describe this in Swift, a
I agree that there is a major problem with “subclasses must override these
methods”. We have no capability to describe this in Swift, and frankly, it
feels like something that ought to be enforced. It’s almost like we were
really asked to conform to a protocol, but the protocol was a class. M
I don’t understand how your “contrived example" could be improved by this new
feature instead of existing features.
It sounds like you’re trying to combine two entirely different things into one
function. One is a filter, which is easily made with .flatMap
let vehicles:[Vehicle] = [Bicycle(), C
Howdy,
Yes, I would like a feature like this. I’m working on a number of apps
where I have a number of concrete types which conform to a protocol.
Deserializing means picking one, and I’d love to be able to declare a
protocol-scoped method which can pick between different subclasses.
Given optionals and closures, is it necessary to support optional protocols?
protocol MyProtocol {
var titleForRow:((_ indexPath:IndexPath)->(String))? { get }
}
One disadvantage is that you need Obj-C, which means it doesn’t run on linux,
or several other platforms.
Another disadvantage
I see what you’re saying now. Thanks.
-Ben
> On Nov 1, 2016, at 11:28 PM, rintaro ishizaki wrote:
>
>
> 2016-11-02 13:14 GMT+09:00 Benjamin Spratling via swift-evolution
> mailto:swift-evolution@swift.org>>:
>
> CGRect(origin:.zero, size:..
>
> is pretty
CGRect(origin:.zero, size:..
is pretty nice. Why do you want to get rid of it?
return values
.flatMap {
//code
}
.filter {
//code
}
.sorted { /* code */ }
.first
is also pretty clean, considering.
> On Nov 1
And there’s our confirmation of hardware emoji keyboard.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Brackets and symbols are definitely operators. Different brackets are used to
represent various quantum mechanical forms and operations.
Arrows are also useful as operators, including but not restricted to chemical
reactions.
-Ben
Sent from my iPhone.
> On Oct 21, 2016, at 7:20 AM, Ben Rimmin
Howdy,
It seems the main question in discussing this proposal is “If $0, $1,
$2, $3 are automatic closure parameters, then what is “$”?”. Another thing
that has also recently come to my attention that Swift does not have a “result
of previous expression” magic identifier as some functio
http://reference.wolfram.com/language/tutorial/Operators.html
They’ve been selling products to mathematicians and scientists for decades.
Some of those symbols are their own, i.e. not included in unicode.
> On Oct 19, 2016, at 8:54 AM, Xiaodi Wu wrote:
>
> Sorry, I've not been very clear on m
> On Oct 19, 2016, at 7:18 AM, Xiaodi Wu wrote:
> How did you decide on those operators instead of ASCII ones?
They are the “correct” mathematical symbols. On my machine, there is a block
of characters explicitly marked as “Math Symbols". It’s a pretty good start
(until you get to the sectio
Howdy,
Some good points about standardizing identifiers.
Some extremely short-sighted points about deleting my formal operators that are
widely recognized as operators, and that I’ve spent months adding into my code.
Frankly, I just couldn’t upgrade until you put them back in.
> Operators
>
> S
> On Oct 18, 2016, at 1:54 PM, Kevin Nattinger via swift-evolution
> wrote:
>
> Part of the beauty of how optionals are implemented in Swift is that the
> compiler doesn’t have to do any magic w.r.t. optionals
> - I strongly dislike the idea of special-casing optionals just to save a
> Byte.
Howdy,
There is already an accepted but not implemented proposal to determine whether
a module can be imported and conditionally compile accordingly.
https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md
While the accepted change is certainly not as compact as your n
>> Benjamin:
>>
>> Implementation wise, weak does *not* currently have the effect of storing
>> associated values. It does however mean that any object with weak references
>> stays allocated after being deinited, until all the weak references are
>> evaluated and zeroed (they are not zeroed
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.
>
> Let's not promote this idea English has comprehensible and easy to refer to
> pronunciation rules ;). It needs reforming :P, but let's keep it for
> English-Evolution ;).
+1
Can you get me on that list? I have a long list of bugs to report. :)
__
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 surp
+1 nested types in protocols
And nested protocols in types.
-1 on throwing properties.
> On Oct 7, 2016, at 10:30 AM, Cao Jiannan via swift-evolution
> wrote:
>
> 1. allow embed type declaration in protocol
> e.g.:
>
> protocol URLProvider {
>fun url() throws -> URL
> }
>
> extension UR
Howdy,
Several months ago, there were a few well-received ideas on the list of adding
functions which would have static-like dispatch directly scoped to protocols,
instead of only to types conforming to those protocols.
From a review of the mailing list, it looks like these ideas got lost amongs
> On Sep 26, 2016, at 3:29 PM, sergio via swift-evolution
> wrote:
>
> HI all,
>
> a debate has recently taken place within the Objective-C/Swift dev community
> concerning the lack in Swift of something “equivalent” to Objective-C runtime
> programming. When using Swift exclusively, there s
Howdy,
As I understand it, In Swift 3, a lack of encapsulation is testable, but
specific keywords to protect a designed encapsulation can’t be introspected,
and thus encapsulation is fragile, i.e. not protectable by unit tests.
For instance, we can write unit-tests that determine if a member's a
bvious to most developers.
Sent from my iPad
> On Sep 13, 2016, at 12:38 PM, Kevin Nattinger wrote:
>
>
>> On Sep 13, 2016, at 10:29 AM, Benjamin Spratling via swift-evolution
>> wrote:
>>
>> Well, then also add an unowned convenience.
>> But I’ve neve
Well, then also add an unowned convenience.
But I’ve never been handed a story from UX that said, “As a user, when I
want the app to crash.”
Using weak, the compiler can tell me when I’ve missed a possible case where
it’s nil.
But the point here is to get closure references that don’t create
Nick, I like where you’re headed with the instance-methods-as-closures idea.
Here’s where I’m headed with it:
Closures are too often used to write the contents of what should be another
function, producing code similar to the “pyramid of doom” avoided by guard. I
now generally write as little
48 matches
Mail list logo
