One stray thread performing an overflowing addition can be the difference
between a secure system and an insecure one. Better to take the process
down.
-- Callionica
On Sun, Jan 15, 2017 at 10:48 PM Russ Bishop via swift-evolution <
swift-evolution@swift.org> wrote:
>
>
> I don’t think it makes
ive because of these implicit captures. It sounds like
>> what you want is a member, and I'm not sure it's worth saving 5 lines to
>> avoid that fact.
>>
>> ~Robert Widmann
>>
>> 2016/12/24 11:45、Callionica (Swift) via swift-evolution <
>> swift-evo
.
>
> ~Robert Widmann
>
> 2016/12/24 11:45、Callionica (Swift) via swift-evolution <
> swift-evolution@swift.org> のメッセージ:
>
> Missed swift-evol in my reply
>
> -- Forwarded message -
> From: Callionica (Swift) <swift-callion...@callionica.com
t;
wrote:
On Dec 23, 2016, at 1:10 AM, Callionica (Swift) via swift-evolution <
swift-evolution@swift.org> wrote:
I'm certainly assuming that users have a basic understanding of scope
(without that, what would be the intention behind defining the class within
the function?).
Despite its
I support the principle of progressive disclosure. I still fail to see how
if class capture were introduced it would prevent people from learning
about classes, functions, closures or any other existing concept in
whatever order the student or teacher preferred.
I disagree that there is any
I'm certainly assuming that users have a basic understanding of scope
(without that, what would be the intention behind defining the class within
the function?).
I'm not clear on what you see as the downside of letting classes capture
locals for users that are unaware of capturing.
On Thu, Dec
Assuming capture were allowed, people defining classes within functions who
didn't want them to capture could position the class definition prior to
any other code in the function so that there would be nothing to capture.
On Thu, Dec 22, 2016 at 4:13 PM Xiaodi Wu via swift-evolution <
It would be a good idea for literals of different types to be easily
recognizable in the source by human readers and extractable from the source
by tools. I'm sure everyone agrees that it's annoying/risky when you can't
even distinguish localizable strings (user messages) from non-localizable
Great. I'd like to see something like this. Couple of comments:
You don't explicitly address overload selection. Do you intend it to
be affected?
Impact on existing code section could be more descriptive.
On Thursday, November 3, 2016, Haravikk via swift-evolution <
swift-evolution@swift.org>
For overridable, but not callable, you can use the technique outlined at
http://www.callionica.com/developer/#swift-protected
(give your method a parameter of a type that only the base class can create)
On Friday, October 7, 2016, Jonathan Hull via swift-evolution <
swift-evolution@swift.org>
Interesting comment about worries that you'd be dispatched to the least
good SS version . A different language with different constraints, but when
LINQ to Objects implementers needed to provide optimized c# implementations
for some operations they chose a runtime type check to dispatch to the
er the original instance is strong-released for the last time. I can't
> remember if this is enabled in release builds as well; under -Ounchecked
> they do become unsafe-unretained.
>
> Jordan
>
>
> On Sep 14, 2016, at 10:51, Callionica (Swift) via swift-evolution <
> swift-e
How do you figure unowned pointers help you detect errors? Dangling
pointers give you no guarantees.
On Wednesday, September 14, 2016, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:
> Sorry to hijack the thread, but I was working to fix the fact that we
> can't have optional
I used this several months ago for extracting data from Any:
// Dynamic cast without bridging
func dynamicCast(_ type: T.Type, _ v: Any)->T? {
guard let result = v as? T where v.dynamicType is T.Type else {
return nil;
}
return result
}
from
The framework design guidelines were for ensuring code consistency and
necessarily included stylistic decisions. There was no ban on using
explicit interface implementation, just reasonable caution to the end goal
of consistency. This is what the framework design guidelines said in 2010:
C# has this feature (called "explicit interface implementation" or
"explicit interface method implementation"). It's useful for implementing
multiple data-like interfaces that have common names like Name, ID, Title,
and Description. It's useful for keeping public interfaces clean. It's
useful for
I support the original proposal. My assumption is that (.fit|.fill) is the
name of a type that can be used anywhere types can be named.
I think the concern about duplicates is misplaced. If the same developer
creates the scaleAndCrop function and the rect function, they may decide to
extract the
This is an interesting proposal, but I think splatting like Python would be
preferable: creators of functions use separate parameters and callers can
expand tuples as necessary by prefixing a tuple at point of use with * to
expand it into separate arguments.
Even with the Swift language as it is
Is there no one that thinks it's sufficient if users can create a tuple
from a list of properties and reuse tuple equality and hash?
Is there no one that thinks it's sufficient if the system were to supply a
named function for comparing two Any's for equality (with reference
equality semantics
It might be worth being more specific with your comparison between the
"lock and key" access control I described and the other techniques
described in this thread. Given that the designers of Swift were familiar
with protected access level from other languages and deliberately chose to
exclude it,
I've used custom warnings and errors in other languages and find them both
useful.
Forgive my ignorance, but does Swift have warning levels, warning IDs and
pragmas/build settings to disable specific warnings? If so, it would be
good to specify exactly how this feature interact with those.
For
I've written up how to provide protected access control for Swift code
today here:
http://www.callionica.com/developer/#swift-protected
No compiler changes necessary for this technique and it distinguishes
between methods that can only be overridden and methods that can be both
called and
Here's demo code for emulating protected in Swift:
https://gist.github.com/callionica/19da0763c0b0b4c504fc5f46d07e8ee8
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
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 a parameter of
This is important and really useful. There's a lot to like here. I have
been thinking about property reflection recently too. Don't have time to
write too much on it now, but was wondering what was the thinking behind
suggesting an opt-in? For me, I would hope that getting access to a
single
I have an alternative you might like to consider: type deduction operators
The input type deduction operator lets you put one or more types in front
of a function to guide type deduction based on the parameters
The output type deduction operator lets you put a type after a function to
guide type
26 matches
Mail list logo
