The term "currency type" is used here to mean a type that is commonly used.
For example, although there are a variety of range types in the Swift standard library ('Range', 'ClosedRange', 'PartialRangeFrom', 'PartialRangeUpTo', etc.), 'Range' is considered the currency type. Similarly, among string types, 'String' is considered the currency type, as opposed to 'Substring', 'StaticString', etc.
Like currency (money), the idea is that APIs in different libraries across different domains of programming will generally take values of the currency type as input and produce values of the currency type as output unless there's a good reason to use a different type.
For Swift System, the stated goal is to provide low-level currency types; if that goal is accomplished, other users of Swift can rely on these types instead of supporting multiple disparate third-party wrappers of system calls that may provide similar functionality just so that they can interoperate with other libraries.
I'm curious what your results would be with the stock Terminal. Do you have the settings that others have talked about under "Security > Privacy > Developer Tools" with Terminal.app listed? If so, and the results are better with Terminal, then it'd be interesting to see if the issue is fixed when you add iTerm2 to the list of exempted apps as well.
Last I heard, my employer (large hospital in New York) is looking to buy. If you could reach out by email, I will pass it along to the relevant people. Thanks!
It's OK to be scared. You're not alone in that. It can be helpful to have someone to talk to. Even as we're trying to keep our physical distance, know that it's OK to reach out for help. And it's also OK to step away from the news for a beat if it's causing you anxiety.
I work at one of the New York hospitals mentioned in this article. Yes, I'm scared too. [Opinions not that of my employer, etc.] But we're all still showing up every day to take care of our patients, and we'll keep doing so until we can't--and then we have backup lined up. There will be hard days, but those will be in the privacy of the hospital, away from prying eyes. New York will pull through.
The problem, of course, is that elsewhere in the chain there was in fact too much checking and too little trust. In this case, it started with not trusting the physician to enter a known dose and requiring an unnecessary conversion, which kicked off the chain of events. This was immediately followed by the problem of alarm fatigue, where practically no set of medication orders can be entered without triggering a slew of useless automated warnings.
The problem of having to deal with too many alarms is not unique to the hospital system mentioned in this article. I discovered the other day that at least one model of ventilator has an alarm that sounds when any object sits in front of the display screen. There was a stethoscope dangling in front of a corner of that screen where nothing was displayed, and an alarm went off of approximately the same urgency as one that would sound if the ventilator were about to blow a patient's lungs out. The same alarm that goes off when a patient's heart rate goes from 60 to 250 bpm sounds when the patient's heart rate goes from 99 to 101 bpm. The pharmacist who was supposed to be checking my orders for sanity once paged me out of a patient room because he couldn't find the URL for the hospital's policy on titrating a particular medication, a document issued by the pharmacy. Most people would agree that it's insane to text and drive on the highway, and yet this is essentially what's being expected of every physician in every hospital while they're making major medical decisions.
This is an interesting demonstration of a hard edge of the language. It's not because Swift holds some sort of grudge against dynamic dispatch, but rather because it's trying to reconcile some subtly incompatible design goals:
1. Adding a default implementation for a protocol requirement shouldn't stop existing types that correctly conform to that protocol from compiling. This is a reasonable user expectation and makes protocol composition a more powerful feature.
2. "Retroactive conformance" should be possible: someone should be able to conform a type they didn't write to a protocol of their own creation. It's a nifty feature that makes Swift extensions very powerful but also sometimes difficult to reason about.
3. Classes should inherit protocol conformances from their superclasses. As some of the Swift core team members have explained, this is not something that absolutely had to be the case, but it seemed sensible initially.
Points (1) and (2) preclude the language from requiring the `override` keyword for the subclass `LazyGreeter` to override a default implementation of a protocol requirement not itself overridden in the superclass `BaseGreeter`, since that would mean that (1) and/or (2) would become impossible. Getting rid of (3) would remove the surprising behavior but it is rather late in the evolution of the language to make such a large change.
The way to reason about this behavior is to consider what are intended "customization points" in the language. It isn't really covered in The Swift Programming Language, but (although not intuitive) it's a fairly teachable concept:
A separate but similar issue exists with the distinction between default implementations of protocol requirements (methods declared in both a protocol and a protocol extension) versus extension methods (methods not declared in a protocol but found in a protocol extension). The former is dynamically dispatched and is considered a customization point for conforming types, whereas the latter can only be shadowed by conforming types but is not a customization point. As described here: https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future
(The Swift standard library actually uses this concept to its advantage. For instance, the inequality operator != is not a customization point for the Equatable protocol and is implemented in an extension method, guaranteeing that !(a == b) is always equivalent to (a != b) in the generic context.)
When implementing subclasses of a third-party open class, only open methods are customization points. In that case, Swift provides compile-time checking to prohibit overriding non-open public methods. This is possible because Swift does not support "retroactive inheritance" from a superclass as it does retroactive conformance to a protocol. Also, the language allows later versions of a third-party open class to stop your existing subclasses from compiling because of a conflict between a later-added superclass method and a pre-existing method in your subclass that now lacks the `override` keyword. In other words, the compiler-enforced prohibition is possible because points (1) and (2) above were not design goals for subclassing as they were for protocol conformance.
In the case illustrated by the present article, where protocols are used in class hierarchies, a third notion of customization points arises. As demonstrated here, a protocol requirement not overridden by a base class is not a customization point for a subclass. The protocol requirement can be shadowed by the subclass but not overridden. Consistent with the design goals enumerated above, this allows for the vendor of a library protocol to provide additional default implementations at a later point without breaking user code. (But if the vendor of a conforming superclass then implements an overriding implementation, your subclass would cease to compile just as it would for any other conflict between superclass methods and subclass methods.)
> Adding a default implementation for a protocol requirement shouldn't stop existing types that correctly conform to that protocol from compiling.
I would disagree with that; adding that default implementation is not a simply internal change. It flat-out changes compilibility; it makes invalid code into valid code:
protocol P {
func f()
}
class C : P {} // Error!
---
protocol P {
func f()
}
extension P {
func f() {}
}
class C : P {} // Okay
Given the trap demonstrated here, the converse should hold as well. Doubly so in light of the ways the compiler (mostly helpfully) enforces various aspects of subclassing, as you pointed out.
In many ways, protocols (right now at least) feel like Swift having its cake but not eating it: strictness floats around them in ways that do not help developers (ugh, PATs!) but is absent where it would:
// This all compiles without any warnings?!
protocol P {
var i: Int { get set }
}
protocol Q : P {
var i: Int { get }
}
class C : Q, P {
var i = 10
}
// Now make a protocol that inherits from another,
// where both are class/AnyObject constrained
//---
struct S : Hashable { // Swift 4.1, synthesized
let s: String
}
extension S : Equatable {
static func == (lhs: S, rhs: S) -> Bool {
// Hashable semantics, smashable semantics. Hold my beer.
return lhs.s.first == rhs.s.first
}
}
Fun anecdote: Born in China, given a Chinese name, then naturalized in Canada. My name was spelled out phonetically on Canadian documents, unsurprisingly. When I return to China now, the name shown on all documents is LASTNAMEFIRSTNAME, not a single Chinese character in sight.
In July 2014, the U.S. dollar was worth around 0.73 euros; today, it is worth about 0.86 euros. In January of last year, it was worth about 0.95 euros, and Apple obviously has an incentive to account for possible short-term exchange fluctuations.
2300 / 0.73 * 0.86 = ~2710
2300 / 0.73 * 0.95 = ~2993
It would appear that currency fluctuations account for a significant portion of that price difference that you're seeing.
2300 EUR in 2014 was ~3151 USD, as you say. At today's exchange rate, 3151 USD is approximately 2710 EUR. In January 2017, 3151 USD was approximately 2993 EUR.
Apple will give themselves a cushion to prevent undesirable pricing discrepancies (or the need for frequent price adjustments) if the U.S. dollar strengthens against the euro, so a product that they sell at 3150 USD after taxes in the United States would reasonably be in the ballpark of 2800-2900 EUR in Europe given exchange rates in the last year or two. This is rather close to the parent post's stated price even without adjusting for inflation.
> Apple will give themselves a cushion to prevent undesirable pricing discrepancies (or the need for frequent price adjustments) if the U.S. dollar strengthens against the euro
Apple is a trillion-dollar company that has people who can and do hedge FX exchange rates on their products to keep costs predictable in local currency terms. As such they don't need a "cushion" - beyond the need to cushion their margins, that is.
(And even if they didn't hedge FX - if they need a cushion now, why didn't they need the same cushion before?)
Before 1931, the so-called Imperial Parliament had the power to legislate for Canada, and any legislation they passed had supremacy over colonial legislation under the Colonial Laws Validity Act, 1865.
Between 1931 and 1982, the UK Parliament had the power to legislate for Canada only with the request and consent of the Canadian government. This arrangement was codified in the Statute of Westminster 1931.
In 1982, on the request and consent of the Canadian government, the UK Parliament removed its own power to legislate for Canada by passing the Canada Act 1982 (UK), which enacted the Constitution Act, 1982.
Canada remains a constitutional monarchy. The monarch of Canada is constitutionally required to be the same physical person as the monarch of the United Kingdom, but they are distinct legal persons (as is the monarch of each province).
As you'll see, this bug is marked as private (at least as of writing this comment). So, as a matter of fact, it does not appear that even the most diligent user had the option of reviewing what's going on. So far, it has not even been disclosed who among the Firefox peers signed off on this change; that information appears to be private as well.
For example, although there are a variety of range types in the Swift standard library ('Range', 'ClosedRange', 'PartialRangeFrom', 'PartialRangeUpTo', etc.), 'Range' is considered the currency type. Similarly, among string types, 'String' is considered the currency type, as opposed to 'Substring', 'StaticString', etc.
Like currency (money), the idea is that APIs in different libraries across different domains of programming will generally take values of the currency type as input and produce values of the currency type as output unless there's a good reason to use a different type.
For Swift System, the stated goal is to provide low-level currency types; if that goal is accomplished, other users of Swift can rely on these types instead of supporting multiple disparate third-party wrappers of system calls that may provide similar functionality just so that they can interoperate with other libraries.