C++-Casting

posted on 08-09-2020

Casting is a conversion process wherein data can be changed from one type to another. C++ has two types of conversions:

Implicit conversion: Conversions are performed automatically by the compiler without the programmer’s intervention.

1 2	int iVariable = 10; float fVariable = iVariable; //Assigning an int to a float will trigger a conversion

Explicit conversion: Conversions are performed only when explicitly specified by the programmer.

1 2	int iVariable = 20; float fVariable = (float) iVariable / 10;

In C++, there are four types of casting operators.

static_cast
const_cast
reinterpret_cast
dynamic_cast

In this article we will only be looking into the first three casting operators as dynamic_cast is very different and is almost exclusively used for handling polymorphism only which we will not be addressing in this article.

`static_cast`

Format:

static_cast<type>(expression);

1	float fVariable = static_cast<float>(iVariable); /This statement converts iVariable which is of type int to float. /

By glancing at the line of code above, you will immediately determine the purpose of the cast as it is very explicit. The static_cast tells the compiler to attempt to convert between two different data types. It will convert between built-in types, even when there is a loss of precision. In addition, the static_cast operator can also convert between related pointer types.

1
2
3

int* pToInt = &iVariable;
float* pToFloat = &fVariable;
float* pResult = static_cast<float*>(pToInt); //Will not work as the pointers are not related (they are of different types).

`const_cast`

Format:

1	const_cast<type>(expression);

void aFunction(int* a)
{
    cout << *a << endl;
}

int main()
{
    int a = 10;
    const int* iVariable = &a;

    aFunction(const_cast<int*>(iVariable));

    return 0;
}

Probably one of the most least used cast, the const_cast does not cast between different types. Instead it changes the “const-ness” of the expression. It can make something const what was not const before, or it can make something volatile/changeable by getting rid of the const. Generally speaking, you will not want to utilise this particular cast in your programs. If you find yourself using this cast, you should stop and rethink your design.

`reinterpret_cast`

Format:

1	reinterpret_cast<type>(expression);

Arguably one of the most powerful cast, the reinterpret_cast can convert from any built-in type to any other, and from any pointer type to another pointer type. However, it cannot strip a variable’s const-ness or volatile-ness. It can however convert between built in data types and pointers without any regard to type safety or const-ness. This particular cast operator should be used only when absolutely necessary.

Async/Await for Swift

posted on 22-03-2020

Authors: Chris Lattner, Joe Groff

Introduction

Modern Cocoa development involves a lot of asynchronous programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls gets complicated. This proposal describes a language extension to make this a lot more natural and less error prone.

This paper introduces a first class Coroutine model to Swift. Functions can opt into to being async, allowing the programmer to compose complex logic involving asynchronous operations, leaving the compiler in charge of producing the necessary closures and state machines to implement that logic.

It is important to understand that this is proposing compiler support that is completely concurrency runtime-agnostic. This proposal does not include a new runtime model (like “actors”) - it works just as well with GCD as with pthreads or another API. Furthermore, unlike designs in other languages, it is independent of specific coordination mechanisms, such as futures or channels, allowing these to be built as library feature. The only runtime support required is compiler support logic for transforming and manipulating the implicitly generated closures.

This draws some inspiration from an earlier proposal written by Oleg Andreev, available here. It has been significantly rewritten by Chris Lattner and Joe Groff.

Motivation: Completion handlers are suboptimal

To provide motivation for why it is important to do something here, lets look at some of the problems that Cocoa (and server/cloud) programmers frequently face.

Problem 1: Pyramid of doom

Sequence of simple operations is unnaturally composed in the nested blocks. Here is a
made up example showing this:

func processImageData1(completionBlock: (result: Image) -> Void) {
    loadWebResource("dataprofile.txt") { dataResource in
        loadWebResource("imagedata.dat") { imageResource in
            decodeImage(dataResource, imageResource) { imageTmp in
                dewarpAndCleanupImage(imageTmp) { imageResult in
                    completionBlock(imageResult)
                }
            }
        }
    }
}

processImageData1 { image in
    display(image)
}

This “pyramid of doom” makes it difficult to keep track of code that is running, and the stack of closures leads to many second order effects.

Problem 2: Error handling

Handling errors becomes difficult and very verbose. Swift 2 introduced an error handling model for synchronous code, but callback-based interfaces do not derive any benefit from it:

func processImageData2(completionBlock: (result: Image?, error: Error?) -> Void) {
    loadWebResource("dataprofile.txt") { dataResource, error in
        guard let dataResource = dataResource else {
            completionBlock(nil, error)
            return
        }
        loadWebResource("imagedata.dat") { imageResource, error in
            guard let imageResource = imageResource else {
                completionBlock(nil, error)
                return
            }
            decodeImage(dataResource, imageResource) { imageTmp, error in
                guard let imageTmp = imageTmp else {
                    completionBlock(nil, error)
                    return
                }
                dewarpAndCleanupImage(imageTmp) { imageResult in
                    guard let imageResult = imageResult else {
                        completionBlock(nil, error)
                        return
                    }
                    completionBlock(imageResult)
                }
            }
        }
    }
}

processImageData2 { image, error in
    guard let image = image else {
        error("No image today")
        return
    }
    display(image)
}

Problem 3: Conditional execution is hard and error-prone

Conditionally executing an asynchronous function is a huge pain. Perhaps the best approach is to write half of the code in a helper “continuation” closure that is conditionally executed, like this:

func processImageData3(recipient: Person, completionBlock: (result: Image) -> Void) {
    let continuation: (contents: image) -> Void = {
      // ... continue and call completionBlock eventually
    }
    if recipient.hasProfilePicture {
        continuation(recipient.profilePicture)
    } else {
        decodeImage { image in
            continuation(image)
        }
    }
}

Problem 4: Many mistakes are easy to make

It’s easy to bail out by simply returning without calling the appropriate block. When forgotten, the issue is very hard to debug:

func processImageData4(completionBlock: (result: Image?, error: Error?) -> Void) {
    loadWebResource("dataprofile.txt") { dataResource, error in
        guard let dataResource = dataResource else {
            return // <- forgot to call the block
        }
        loadWebResource("imagedata.dat") { imageResource, error in
            guard let imageResource = imageResource else {
                return // <- forgot to call the block
            }
            ...
        }
    }
}

When you do not forget to call the block, you can still forget to return after that.
Thankfully guard syntax protects against that to some degree, but it’s not always relevant.

func processImageData5(recipient:Person, completionBlock: (result: Image?, error: Error?) -> Void) {
    if recipient.hasProfilePicture {
        if let image = recipient.profilePicture {
            completionBlock(image) // <- forgot to return after calling the block
        }
    }
    ...
}

Problem 5: Because completion handlers are awkward, too many APIs are defined synchronously

This is hard to quantify, but the authors believe that the awkwardness of defining and using asynchronous APIs (using completion handlers) has led to many APIs being defined with apparently synchronous behavior, even when they can block. This can lead to problematic performance and responsiveness problems in UI applications - e.g. spinning cursor. It can also lead to the definition of APIs that cannot be used when asynchrony is critical to achieve scale, e.g. on the server.

Problem 6: Other “resumable” computations are awkward to define

The problems described above are on specific case of a general class of problems involving “resumable” computations. For example, if you want to write code that produces a list of squares of numbers, you might write something like this:

1
2
3

for i in 1...10 {
    print(i*i)
}

However, if you want to write this as a Swift sequence, you have to define this as something that incrementally produces values. There are multiple ways to do this (e.g. using AnyIterator, or the sequence(state:,next:) functions), but none of them approach the clarity and obviousness of the imperative form.

In contrast, languages that have generators allow you to write something more close to this:

func getSequence() -> AnySequence<Int> {
    let seq = sequence {
        for i in 1...10 {
            yield(i*i)
        }
    }
    return AnySequence(seq)
}

It is the responsibility of the compiler to transform the function into a form that incrementally produces values, by producing a state machine.

Proposed Solution: Coroutines

These problem have been faced in many systems and many languages, and the abstraction of coroutines is a standard way to address them. Without delving too much into theory, coroutines are an extension of basic functions that allow a function to return a value or be suspended. They can be used to implement generators, asynchronous models, and other capabilities - there is a large body of work on the theory, implementation, and optimization of them.

This proposal adds general coroutine support to Swift, biasing the nomenclature and terminology towards the most common use-case: defining and using asynchronous APIs, eliminating many of the problems working with completion handlers. The choice of terminology (async vs yields) is a bikeshed topic which needs to be addressed, but isn’t pertinent to the core semantics of the model. See Alternate Syntax Options at the end for an exploration of syntactic options in this space.

It is important to understand up-front, that the proposed coroutine model does not interface
with any particular concurrency primitives on the system: you can think of it as syntactic
sugar for completion handlers. This means that the introduction of coroutines would not
change the queues that completion handlers are called on, as happens in some other systems.

Async semantics

Today, function types can be normal or throwing. This proposal extends them to also be allowed to be async. These are all valid function types:

(Int) -> Int               // #1: Normal function
(Int) throws -> Int        // #2: Throwing function
(Int) async -> Int         // #3: Asynchronous function
(Int) async throws -> Int  // #4: Asynchronous function, can also throw.

Just as a normal function (#1) will implicitly convert to a throwing function (#2), an async function (#3) implicitly converts to a throwing async function (#4).

On the function declaration side of the things, you can declare a function as being asynchronous just as you declare it to be throwing, but use the async keyword:

func processImageData() async -> Image { ... }

// Semantically similar to this:
func processImageData(completionHandler: (result: Image) -> Void) { ... }

Calls to async functions can implicitly suspend the current coroutine. To make this apparent to maintainers of code, you are required to “mark” expressions that call async functions with the new await keyword (exactly analogously to how try is used to mark subexpressions that contain throwing calls). Putting these pieces together, the first example (from the pyramid of doom explanation, above) can be rewritten in a more natural way:

func loadWebResource(_ path: String) async -> Resource
func decodeImage(_ r1: Resource, _ r2: Resource) async -> Image
func dewarpAndCleanupImage(_ i : Image) async -> Image

func processImageData1() async -> Image {
  let dataResource  = await loadWebResource("dataprofile.txt")
  let imageResource = await loadWebResource("imagedata.dat")
  let imageTmp      = await decodeImage(dataResource, imageResource)
  let imageResult   =  await dewarpAndCleanupImage(imageTmp)
  return imageResult
}

Under the hood, the compiler rewrites this code using nested closures like in example processImageData1 above. Note that every operation starts only after the previous one has completed, but each call site to an async function could suspend execution of the current function.

Finally, you are only allowed to invoke an async function from within another async function or closure. This follows the model of Swift 2 error handling, where you cannot call a throwing function unless you’re in a throwing function or inside of a do/catch block.

Entering and leaving async code

In the common case, async code ought to be invoking other async code that has been dispatched by the framework the app is built on top of, but at some point, an async process needs to spawn from a controlling synchronous context, and the async process needs to be able to suspend itself and allow its continuation to be scheduled by the controlling context. We need a couple of primitives to
enable entering and suspending an async context:

// NB: Names subject to bikeshedding. These are low-level primitives that most
// users should not need to interact with directly, so namespacing them
// and/or giving them verbose names unlikely to collide or pollute code
// completion (and possibly not even exposing them outside the stdlib to begin
// with) would be a good idea.

/// Begins an asynchronous coroutine, transferring control to `body` until it
/// either suspends itself for the first time with `suspendAsync` or completes,
/// at which point `beginAsync` returns. If the async process completes by
/// throwing an error before suspending itself, `beginAsync` rethrows the error.
func beginAsync(_ body: () async throws -> Void) rethrows -> Void

/// Suspends the current asynchronous task and invokes `body` with the task's
/// continuation closure. Invoking `continuation` will resume the coroutine
/// by having `suspendAsync` return the value passed into the continuation.
/// It is a fatal error for `continuation` to be invoked more than once.
func suspendAsync<T>(
  _ body: (_ continuation: @escaping (T) -> ()) -> ()
) async -> T

/// Suspends the current asynchronous task and invokes `body` with the task's
/// continuation and failure closures. Invoking `continuation` will resume the
/// coroutine by having `suspendAsync` return the value passed into the
/// continuation. Invoking `error` will resume the coroutine by having
/// `suspendAsync` throw the error passed into it. Only one of
/// `continuation` and `error` may be called; it is a fatal error if both are
/// called, or if either is called more than once.
func suspendAsync<T>(
  _ body: (_ continuation: @escaping (T) -> (),
           _ error: @escaping (Error) -> ()) -> ()
) async throws -> T

These are similar to the “shift” and “reset” primitives of delimited continuations. These enable a non-async function to call an async function. For example, consider this
@IBAction written with completion handlers:

@IBAction func buttonDidClick(sender:AnyObject) {
  // 1
  processImage(completionHandler: {(image) in
    // 2
    imageView.image = image
  })
  // 3
}

This is an essential pattern, but is itself sort of odd: an async operation is being fired off immediately (#1), then runs the subsequent code (#3), and the completion handler (#2) runs at some time later — on some queue (often the main one). This pattern frequently leads to mutation of global state (as in this example) or to making assumptions about which queue the completion handler is run on. Despite these problems, it is essential that the model encompasses this pattern, because it is a practical necessity in Cocoa development. With this proposal, it would look like this:

@IBAction func buttonDidClick(sender:AnyObject) {
  // 1
  beginAsync {
    // 2
    let image = await processImage()
    imageView.image = image
  }
  // 3
}

These primitives enable callback-based APIs to be wrapped up as async coroutine APIs:

// Legacy callback-based API
func getStuff(completion: (Stuff) -> Void) { ... }

// Swift wrapper
func getStuff() async -> Stuff {
  return await suspendAsync { continuation in
    getStuff(completion: continuation)
  }
}

Functionality of concurrency libraries such as libdispatch and pthreads can
also be presented in coroutine-friendly ways:

extension DispatchQueue {
  /// Move execution of the current coroutine synchronously onto this queue.
  func syncCoroutine() async -> Void {
    await suspendAsync { continuation in
      sync { continuation }
    }
  }

  /// Enqueue execution of the remainder of the current coroutine
  /// asynchronously onto this queue.
  func asyncCoroutine() async -> Void {
    await suspendAsync { continuation in
      async { continuation }
    }
  }
}

func queueHopping() async -> Void {
  doSomeStuff()
  await DispatchQueue.main.syncCoroutine()
  doSomeStuffOnMainThread()
  await backgroundQueue.asyncCoroutine()
  doSomeStuffInBackground()
}

Generalized abstractions for coordinating coroutines can also be built. The simplest of these is a future, a value that represents a future value which may not be resolved yet. The exact design for a Future type is out of scope for this proposal (it should be its own follow-on proposal), but an example proof of concept could look like this:

class Future<T> {
  private enum Result { case error(Error), value(T) }
  private var result: Result? = nil
  private var awaiters: [(Result) -> Void] = []

  // Fulfill the future, and resume any coroutines waiting for the value.
  func fulfill(_ value: T) {
    precondition(self.result == nil, "can only be fulfilled once")
    let result = .value(value)
    self.result = result
    for awaiter in awaiters {
      // A robust future implementation should probably resume awaiters
      // concurrently into user-controllable contexts. For simplicity this
      // proof-of-concept simply resumes them all serially in the current
      // context.
      awaiter(result)
    }
    awaiters = []
  }

  // Mark the future as having failed to produce a result.
  func fail(_ error: Error) {
    precondition(self.result == nil, "can only be fulfilled once")
    let result = .error(error)
    self.result = result
    for awaiter in awaiters {
      awaiter(result)
    }
    awaiters = []
  }

  func get() async throws -> T {
    switch result {
    // Throw/return the result immediately if available.
    case .error(let e)?:
      throw e
    case .value(let v)?:
      return v
    // Wait for the future if no result has been fulfilled.
    case nil:
      return await suspendAsync { continuation, error in
        awaiters.append({
          switch $0 {
          case .error(let e): error(e)
          case .value(let v): continuation(v)
          }
        })
      }
    }
  }

  // Create an unfulfilled future.
  init() {}

  // Begin a coroutine by invoking `body`, and create a future representing
  // the eventual result of `body`'s completion.
  convenience init(_ body: () async -> T) {
    self.init()
    beginAsync {
      do {
        self.fulfill(await body())
      } catch {
        self.fail(error)
      }
    }
  }
}

To reiterate, it is well known that this specific implementation has performance and API weaknesses, the point is merely to sketch how an abstraction like this could be built on top of async/await.

Futures allow parallel execution, by moving await from the call to the result when it is needed, and wrapping the parallel calls in individual Future objects:

func processImageData1a() async -> Image {
  let dataResource  = Future { await loadWebResource("dataprofile.txt") }
  let imageResource = Future { await loadWebResource("imagedata.dat") }

  // ... other stuff can go here to cover load latency...

  let imageTmp    = await decodeImage(dataResource.get(), imageResource.get())
  let imageResult = await dewarpAndCleanupImage(imageTmp)
  return imageResult
}

In the above example, the first two operations will start one after another, and the unevaluated computations are wrapped into a Future value. This allows all of them to happen concurrently (in a way that need not be defined by the language or by the Future implementation), and the function will wait for completion of them before decoding the image. Note that await does not block flow of execution: if the value is not yet ready, execution of the current async function is suspended, and control flow passes to something higher up in the stack.

Other coordination abstractions such as Communicating Sequential Process channels or Concurrent ML events can also be developed as libraries for coordinating coroutines; their implementation is left as an exercise for the reader.

Conversion of imported Objective-C APIs

Full details are beyond the scope of this proposal, but it is important to enhance the importer to project Objective-C completion-handler based APIs into async forms. This is a transformation comparable to how NSError** functions are imported as throws functions. Having the importer do this means that many Cocoa APIs will be modernized en masse.

There are multiple possible designs for this with different tradeoffs. The maximally source compatible way to do this is to import completion handler-based APIs in two forms: both the completion handler and the async form. For example, given:

// Before
- (void) processImageData:(void(^)())completionHandler;
- (void) processImageData:(void(^)(Image* __nonnull image))completionHandler;
- (void) processImageData:(void(^)(Image* __nullable image1, NSError* __nullable error))completionHandler;
- (void) processImageData:(void(^)(Image* __nullable half1, Image* __nullable half2, NSError* __nullable error))completionHandler;
- (void) processImageData:(void(^)(NSError* __nullable error))completionHandler;

The declarations above are imported both in their normal completion handler form, but also in their nicer async forms:

func processImageData() async
func processImageData() async -> Image
func processImageData() async throws -> Image
func processImageData() async throws -> (half1: Image, half2: Image)
func processImageData() async throws

There are many details that should be defined as part of this importing process - for example:

What are the exact rules for the transformation?
Are multiple result functions common enough to handle automatically?
Would it be better to just import completion handler functions only as async in Swift 5 mode, forcing migration?
What should happen with the non-Void-returning completion handler functions (e.g. in URLSession)?
Should Void-returning methods that are commonly used to trigger asynchronous operations in response to events, such as IBAction methods, be imported as async -> Void?

Without substantial ObjC importer work, making a clean break and forcing migration in Swift 5 mode would be the most practical way to preserve overridability, but would create a lot of churn in 4-to-5 migration. Alternatively, it may be acceptable to present the async versions as final wrappers over the underlying callback-based interfaces; this would subclassers to work with the callback-based interface, but there are generally fewer subclassers than callers.

Interaction with existing features

This proposal dovetails naturally with existing language features in Swift, here are a few examples:

Error handling

Error handling syntax introduced in Swift 2 composes naturally with this asynchronous model.

// Could throw or be interrupted:
func processImageData() async throws -> Image

// Semantically similar to:
func processImageData(completionHandler: (result: Image?, error: Error?) -> Void)

Our example thus becomes (compare with the example processImageData2):

func loadWebResource(_ path: String) async throws -> Resource
func decodeImage(_ r1: Resource, _ r2: Resource) async throws -> Image
func dewarpAndCleanupImage(i: Image) async throws -> Vegetable

func processImageData2() async throws -> Image {
  let dataResource  = try await loadWebResource("dataprofile.txt")
  let imageResource = try await loadWebResource("imagedata.dat")
  let imageTmp      = try await decodeImage(dataResource, imageResource)
  let imageResult   = try await dewarpAndCleanupImage(imageTmp)
  return imageResult
}

Coroutines address one of the major shortcomings of the Swift 2 error model,
that it did not interoperate well with callback-oriented asynchronous APIs and
required clumsy boilerplate to propagate errors across callback boundaries.

Closure type inference

Because the await keyword is used at all points where execution may be suspended, it is simple for the compiler to determine whether a closure is async or not: it is if the body includes an await. This works exactly the same way that the presence of try in a closure causes it to be inferred as a throwing closure. You can also explicitly mark a closure as async using the standard form of:

1	let myClosure = { () async -> () in ... }

`defer` and abandonment

Coroutines can be suspended, and while suspended, there is the potential for a coroutine’s execution to be abandoned if all references to its continuation
closure(s) are released without being executed:

/// Shut down the current coroutine and give its memory back to the
/// shareholders.
func abandon() async -> Never {
  await suspendAsync { _ = $0 }
}

It is to be expected that, upon abandonment, any references captured in wait by the continuation should be released, as with any closure. However, there may be other cleanup that must be guaranteed to occur. defer serves the general
role of “guaranteed cleanup” in synchronous code, and it would be a natural
extension to add the guarantee that defer-ed statements also execute as part
of cleaning up an abandoned coroutine:

func processImageData() async throws -> Image {
  startProgressBar()
  defer {
    // This will be called when error is thrown, when all operations
    // complete and a result is returned, or when the coroutine is
    // abandoned. We don't want to leave the progress bar animating if
    // work has stopped.
    stopProgressBar()
  }

let dataResource  = try await loadWebResource("dataprofile.txt")
  let imageResource = try await loadWebResource("imagedata.dat")
  do {
    let imageTmp    = try await decodeImage(dataResource, imageResource)
  } catch _ as CorruptedImage {
    // Give up hope now.
    await abandon()
  }
  return try await dewarpAndCleanupImage(imageTmp)
}

This fills in another gap in the expressivity of callback-based APIs, where it is difficult to express cleanup code that must execute at some point regardless of whether the callback closure is really called. However, abandonment should not be taken as a fully-baked “cancellation” feature; if cancellation is important, it should continue to be implemented by the programmer where needed, and there are many standard patterns that can be applied. Particularly when coupled with error handling, common cancellation patterns become very elegant:

@IBAction func processImageData(sender: AnyObject) {
  beginAsync {
    do {
      let dataResource  = try await imageProcessor.loadWebResource("dataprofile.txt")
      let imageResource = try await imageProcessor.loadWebResource("imagedata.dat")
      let imageTmp      = try await imageProcessor.decodeImage(dataResource, imageResource)
      let imageResult   = try await imageProcessor.dewarpAndCleanupImage(imageTmp)
      display(imageResult)
    } catch CocoaError.userCancelled {
      // Ignore, user quit the kitchen.
    } catch {
      // Some really interesting error happened
      presentError(error)
    }
  }
}

@IBAction func stopImageProcessing(sender: AnyObject) {
  imageProcessor.cancel()
}

Internally, imageProcessor may use NSOperation or a custom cancelled flag. The intent of this section is to give a single example of how to approach this, not to define a normative or all-encompassing approach that should be used in all cases.

Completion handlers with multiple return values

Completion handler APIs may have multiple result arguments (not counting an error argument). These are naturally represented by tuple results in async functions:

// Before
func processImageHalves(completionHandler: (part1: Image?, part2: Image?, error: Error?) -> Void)

// After
func processImageHalves() async throws -> (Image, Image)

Source Compatibility

This is a generally additive feature, but it does take async and await as keywords, so it will break code that uses them as identifiers. This is expected to have very minor impact: the most pervasive use of async as an identifier occurs in code that works with dispatch queues, but fortunately keywords are allowed as qualified member names, so code like this doesn’t need any change:

1	myQueue.async { ... }

That said, there could be obscure cases that break. One example that occurs in the Swift testsuite is of the form:

extension DispatchQueue {
  func myThing() {
    async {
        ...
    }
  }
}

This can be addressed by changing the code to use self.async or backticks. The compiler should be able to detect a large number of these cases and produce a fixit.

Effect on ABI stability

This proposal does not change the ABI of any existing language features, but does introduce a new concept that adds to the ABI surface area, including a new mangling and calling convention.

Alternate Syntax Options

Here are a couple of syntax level changes to the proposal that are worth discussing, these don’t fundamentally change the shape of the proposal.

Spelling of `async` keyword

Instead of spelling the function type modifier as async, it could be spelled as yields, since the functionality really is about coroutines, not about asynchrony by itself. The recommendation to use async/await biases towards making sure that the most common use case (asynchrony) uses industry standard terms. The other coroutine use cases would be much less common, at least according to the unscientific opinion of the proposal authors.

To give an idea of what this could look like, here’s the example from above resyntaxed:

func loadWebResource(_ path: String) yields -> Resource
func decodeImage(_ r1: Resource, _ r2: Resource) yields -> Image
func dewarpAndCleanupImage(_ i : Image) yields -> Image

func processImageData1() yields -> Image {
  let dataResource  = yield loadWebResource("dataprofile.txt")
  let imageResource = yield loadWebResource("imagedata.dat")
  let imageTmp      = yield decodeImage(dataResource, imageResource)
  let imageResult   = yield dewarpAndCleanupImage(imageTmp)
  return imageResult
}

Make `async` be a subtype of `throws` instead of orthogonal to it

It would be a great simplification of the language model to make the async modifier on a function imply that the function is throwing, instead of making them orthogonal modifiers. From an intuitive perspective, this makes sense because many of the sorts of operations that are asynchronous (e.g. loading a resource, talking to the network, etc) can also fail. There is also precedent from many other systems that use async/await for this; for example, .NET Tasks and Javascript promises both combine error handling with async sequencing. One could argue that that’s because .NET and Javascript’s established runtimes both feature pervasive implicit exceptions; however, popular async frameworks for the Rust programming language, such as tokio.rs, have also chosen to incorporate error handling directly into their Future constructs, because doing so was found to be more practical and ergonomic than trying to compose theoretically-orthogonal Future<T> and Result<T> constructs.

If we made async a subtype of throws, then instead of four kinds of function type, we’d only have three:

1
2
3

(Int) -> Int               // Normal function
(Int) throws -> Int        // Throwing function
(Int) async -> Int         // Asynchronous function, can also throw

The try marker could also be dropped from try await, because all awaits would be known to throw. For user code, you would never need the ugly async throws modifier stack.

A downside to doing this is that Cocoa in practice does have a number of completion handler APIs that do not take error arguments, and not having the ability to express that would make the importer potentially lose type information. Many of these APIs express failure in more limited ways, such as passing nil into the completion closure, passing in a BOOL to indicate success, or communicating status via side properties of the coordinating object; auditing for and recognizing all of these idioms would complicate the importer and slow the SDK modernization process. Even then, Swift subclassers overriding the async forms of these APIs would be allowed by the language to throw errors even though the error cannot really be communicated across the underlying Objective-C interface.

Make `async` default to `throws`

The other way to factor the complexity is to make it so that async functions default to throwing, but still allow non-throwing async functions to be expressed with nonthrowing (or some other spelling). This provides this model:

(Int) -> Int                     // Normal function
(Int) throws -> Int              // Throwing function
(Int) async -> Int               // Asynchronous function, can also throw.
(Int) async(nonthrowing) -> Int  // Asynchronous function, doesn't throw.

This model provides a ton of advantages: it is arguably the right defaults for the vast majority of clients (reducing boilerplate and syntactic noise), provides the ability for the importer and experts to get what they want. The only downside of is that it is a less obvious design than presenting two orthogonal axes, but in the opinion of the proposal authors, this is probably the right set of tradeoffs.

Behavior of `beginAsync` and `suspendAsync` operations

For async code to be able to interact with synchronous code, we need at least two primitive operations: one to enter a suspendable context, and another to suspend the current context and yield control back to the outer context. Aside from the obvious naming bikeshed, there are some other design details to consider. As proposed, beginAsync and continuation closures return Void to the calling context, but it may be desirable instead to have them return a value indicating whether the return was because of suspension or completion of the async task, e.g.:

/// Begin execution of `body`. Return `true` if it completes, or `false` if it
/// suspends.
func beginAsync(_ body: () async -> ()) -> Bool
/// Suspend execution of the current coroutine, passing the current continuation/// into `body` and then returning `false` to the controlling context
func suspendAsync<T>(_ body: (_ resume: (T) -> Bool) -> Void) async -> T

Instead of representing the continuation as a plain function value passed into the suspendAsync primitive, a specialized Continuation<T> type could be devised. Continuations are one-shot, and a nominal continuation type could statically enforce this by being a move-only type consumed by the resume operation. The continuation could also be returned by beginAsync or resuming a continuation instead of being passed into suspendAsync, which would put the responsibility for scheduling the continuation into the code that starts the coroutine instead of in the code that causes the suspension. There are tradeoffs to either approach.

Alternatives Considered

Include `Future` or other coordination abstractions in this proposal

This proposal does not formally propose a Future type, or any other coordination abstractions. There are many rational designs for futures, and a lot of experience working with them. On the other hand, there are also completely different coordination primitives that can be used with this coroutine design, and incorporating them into this proposal only makes it larger.

Furthermore, the shape and functionality of a future may also be affected by Swift’s planned evolution. A Future type designed for Swift today would need to be a class, and therefore need to guard against potentially multithreaded access, races to fulfill or attempts to fulfill multiple times, and potentially unbounded queueing of awaiting coroutines on the shared future; however, the introduction of ownership and move-only types would allow us to express futures as a more efficient move-only type requiring exclusive ownership to be forwarded from the fulfilling task to the receiving task, avoiding the threading and queueing problems of a class-based approach, as seen in Rust’s tokio.rs framework. tokio.rs and the C++ coroutine TR also both take the approach of making futures/continuations into templated/generic traits instead of a single concrete implementation, so that the compiler can deeply specialize and optimize state machines for composed async operations. tokio.rs and the C++ coroutine TR also both take the approach of making futures/continuations into templated/generic traits instead of a single concrete implementation, so that the compiler can deeply specialize and optimize state machines for composed async operations. Whether that is a good design for Swift as well needs further exploration.

Have async calls always return a `Future`

The most commonly cited alternative design is to follow the model of (e.g.) C#, where calls to async functions return a future (aka Task in C#), instead of futures being a library feature separable from the core language. Going this direction adds async/await to the language instead of adding a more general coroutine feature.

Despite this model being widely know, we believe that the proposed design is
superior for a number of reasons:

Coroutines are generally useful language features beyond the domain of async/await. For example, building async/await into the compiler would require building generators in as well.
The proposed design eliminates the problem of calling an API (without knowing it is async) and getting a Future<T> back instead of the expected T result type. C# addresses this by suggesting that all async methods have their name be suffixed with Async, which is suboptimal.
By encoding async as a first-class part of function types, closure literals can also be transparently async by contextual type inference. In the future, mechanisms like rethrows can be extended to allow polymorphism over asynchrony for higher-level operations like map to work as expected without creating intermediate collections of Future<T>, although this proposal does not propose any such abstraction mechanisms in the short term.
The C# model for await is a unary prefix keyword, which does not compose well in the face of chaining. Wherein C# you may have to write something like x = await (await foo()).bar(), with the proposed design you can simply write x = await foo().bar() for the same reasons that you don’t have to write try on every single call in a chain that can throw.
It is useful to be able to design and discuss futures as an independent standard library feature without tying the entire success or failure of coroutines as a language proposal to Future‘s existence.
There are multiple different interesting abstractions besides futures to consider. By putting the details of them in the standard library, other people can define and use their own abstractions where it makes sense.
Requiring a future object to be instantiated at every await point adds overhead. Since a major use case for this feature is to adapt existing Cocoa APIs, which already use callbacks, queues, target-action, or other mechanisms to coordinate the scheduling of the continuation of an async task, introducing a future into the mix would be an additional unnecessary middleman incurring overhead when wrapping these APIs, when in most cases there is already a direct consumer for the continuation point.
A design that directly surfaces a monadic type like Future as the result of an async computation heavily implies a compiler-driven coroutine transform, whereas this design is more implementation-agnostic. Compiler-transformed coroutines are a great compromise for integrating lightweight tasks into an existing runtime model that’s already heavily callstack-dependent, or one aims to maintain efficient interop with C or other languages that heavily constrain the implementation model, and Swift definitely has both. It is conceivable that, in the eventual future, a platform such as Swift-on-the-server could provide a pure- or predominantly-Swift ABI where enough code is pure Swift to make cheap relocatable stacks the norm and overhead on C interop acceptable, as has happened with the Go runtime. This could make async a no-op at runtime, and perhaps allow us to consider eliminating the annotation altogether. The semantic presence of a future object between every layer of an async process would be an obstacle to the long-term efficiency of such a platform.

The primary argument for adding async/await (and then generators) to the language as first-class language features is that they are the vastly most common use-case of coroutines. In the author’s opinion, the design as proposed gives something that works better than the C# model in practice, while also providing a more useful/general language model.

Have a generalized “do notation” for monadic types

Another approach to avoiding the one-true-future-type problem of C# could be to have a general language feature for chaining continuations through a monadic interface. Although this provides a more general language feature, it still has many of the shortcomings discussed above; it would still perform only a shallow transform of the current function body and introduce a temporary value at every point the coroutine is “awaited”. Monads also compose poorly with each other, and require additional lifting and transformation logic to plumb through higher-order operations, which were some of the reasons we also chose not to base Swift’s error handling model on sugar over Result types. Note that the delimited continuation primitives offered in this proposal are general purpose and can in fact be used to represent monadic unwrapping operations for types like Optional or Result:

func doOptional<T>(_ body: (_ unwrap: (T?) async -> T) async -> T?) -> T? {
  var result: T?

  func unwrap(_ value: T?) async -> T {
    if let value = value {
      return value
    }
    suspendAsync { _ in result = nil }
  }

  beginAsync {
    body(unwrap)
  }
}

Monads that represent repeated or nondeterministic operations would not be representable this way due to the one-shot constraint on continuations, but representing such computations as straight-line code in an imperative language with shared mutable state seems like a recipe for disaster to us.

Potential Future Directions

This proposal has been kept intentionally minimal, but there are many possible ways to expand this in the future. For example:

New Foundation, GCD, and Server APIs

Given the availability of convenient asynchrony in Swift, it would make sense to introduce new APIs to take advantage of it. Filesystem APIs are one example that would be great to see. The Swift on Server working group would also widely adopt these features. GCD could also provide new helpers for allowing () async -> Void coroutines to be enqueued, or for allowing a running coroutine to move its execution onto a different queue.

Documentation

As part of this introduction it makes sense to extend the Swift API design guidelines and other documentation to describe and encourage best practices in asynchronous API design.

`rethrows` could be generalized to support potentially `async` operations

The rethrows modifier exists in Swift to allow limited abstraction over function types by higher order functions. It would be possible to define a similar mechanism to allow abstraction over async operations as well. More generally, by modeling both throws and async as effects on function types, we can eventually provide common abstraction tools to abstract over both effects in protocols and generic code, simultaneously addressing the “can’t have a Sequence that throws“ and “can’t have a Sequence that’s async“ kinds of limitations in the language today.

Blocking calls

Affordances could be added to better call blocking APIs from async functions and to hard wait for an async function to complete. There are significant tradeoffs and wide open design space to explore here, and none of it is necessary for the base proposal.

Fix queue-hopping Objective-C completion handlers

One unfortunate reality of the existing Cocoa stack is that many asynchronous methods are
unclear about which queue they run the completion handler on. In fact, one of the top hits
for implementing completion handlers on Stack Overflow includes this Objective-C code:

- (void)asynchronousTaskWithCompletion:(void (^)(void))completion;
{
  dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

    // Some long running task you want on another thread

    dispatch_async(dispatch_get_main_queue(), ^{
      if (completion) {
        completion();
      }
    });
  });
}

Note that it runs the completion handler on the main queue, not on the queue which it was
invoked on. This disparity causes numerous problems for Cocoa programmers, who would
probably defensively write the @IBAction above like this (or else face a possible race
condition):

@IBAction func buttonDidClick(sender:AnyObject) {
  beginAsync {
    let image = await processImageData()
    // Do the update on the main thread/queue since it owns imageView.
    mainQ.async {
      imageView.image = image
    }
  }
}

This can be fixed in the Objective-C importer, which is going to be making thunks for the
completion-handler functions anyway: the thunk could check to see if the completion handler
is being run on a different queue than the function was invoked on, and if so, enqueue the
completion handler on the original queue.

Thanks

Thanks to @oleganza for the original draft which influenced this!

An Innovative Approach to Re-Design Mobile Learning Experience with X5Learn

posted on 22-03-2020

Patrick Wu, Yinrui Hu

About Us

Hello, we are Team 4. My name is Patrick Wu, the team lead and a 2nd-Year Computer Science student at University College London. My interest mainly lies in low-level system design and networked systems. For this summer, I’m going to intern at a trading firm working on its infrastructural components.
My teammate Yinrui(Felix) Hu, is also a second-year computer science student studying at UCL. He is mostly interested in artificial intelligence and cyber-security related fields.
I am delighted to be working with Yinrui this year, and developed a brand new mobile application with many innovative approaches for UCL’s X5Learn research team, our industrial partner.

What have we been working on?

Online Education is no stranger to us, students, nowadays, as we have been utilising this extensively in day to day life. For instance, due to the recent COVID-19 outbreak, UCL students would all logon to Moodle to conduct remote learning through contents of formats including but not limited to videos, texts and audios. Apart from Moodle, there are such a great number of alternatives out there, e.g. Coursera, Khan Academy, LinkedIn Learning, MIT Open Courseware and many more. The trouble mainly lies which platform to choose instead of a lack of learning materials. As a student, we have spent way too long looking for a useful resource rather than learning itself. Therefore, X5GON and X5Learn as a Software-as-a-Service (SaaS), can solve this problem for you.

The main focus of X5GON development team is creating a solution that will help users/students find what they need not just in OER repositories, but across all open educational resources on the web. This solution will adapt to the user’s needs and learn how to make ongoing customised recommendations and suggestions through a truly interactive and impactful learning experience.

Figure 1. A demonstration of X5Learn’s website version.

Our goal, as a student team, is to develop a mobile application that utilises the X5Learn platform and provide an authentic and mobile-friendly user experience. With this mobile application, the X5Learn system would be able to attract more customers from the mobile platform and enable users to access their customised X5Learn learning contents at all times.

What are the technical challenges?

The critical challenge above all is to differentiate our application from other proprietary learning platforms. We continuously ask ourselves how to make the app more accessible and easy to navigate around for users. Given the fact there are many established applications out there, our team considered trying them out ourselves and conduct double-blind experiments on UI, app responsiveness and content relevancy experiments. We have learnt a lot in the process and greatly influenced our design of X5GON-Mobile afterwards.

Whilst we are testing out multiple applications under the eduroam network environment, there was one significant issue that emerged out of the dark. Some apps, under mediocre network environment, suffered from constant loss of network connection and plodding loading speed. Also, given the fact that the X5Learn usually takes 10 to 15 seconds to process videos and generate analytic reports, these together makes the app increasingly laggy and unusable at all under such circumstances. This issue of performance we noticed at an early stage influenced our application design and development process thereafter and is proven to be a significant differentiating factor for our application.

Last but not least, another essential technical challenge we faced was that the X5Learn was in ongoing development. Hence, many of the functionalities we aim to accomplish in our project are still in development or doesn’t exist as an API from the back-end. This caused us considerable trouble initially. However, we were able to overcome this difficulty eventually and made our application more adaptable to this type of situation, which would be beneficial for future expansion of the whole platform after our delivery of the project.

How did we solve them?

Figure 2. An overview of the technologies used in this project.

We tackled challenges above using advanced technology provided by Apple, the open-source community and algorithms written by ourselves.

Figure 3. A comparison between traditional learning app and our approach.

From a design perspective, we took the information-feed approach rather than listing all courses available for the users find. As on most other platforms, users would have to search for what they want to learn, we actively push this information to the screen for users to choose from, similar to video sites but unlike a learning platform. Our design also utilises an innovative way of enabling users to read bullet-points or browse external supportive contents. Users can scroll to a sidebar whilst not stopping the video and start from there. They can also minimise the video to let it play as a floating window at the bottom of the screen. This design received great feedback from our clients and users at our testing stage.

Figure 4. A demonstration of our app’s performance on videos.

With regards to the performance of the application, we utilised extensive caching and predicting techniques to minimise the lag and increase the responsiveness. First of all, the choice of using Swift to develop a native iOS application provides us with a faster foundation compared to hybrid frameworks like React Native. More so, our aggressive pre-loading daemon utilised a HashMap storing technique and regularly fetches first 20-seconds of content whenever user finds the thumbnail on display. Although we did make a trade-off of having more background tasks, which is negligible, app users now receive a notably faster application and smoother learning experience.

As a project that has both the ongoing development of front-end and back-end at the same time, we found it challenging to adapt to the constant changing API as an external mobile application. Therefore, we then utilised SwiftSoup, an external parser for HTML,
together with our own algorithm to analyse changing API endpoints on the fly and self-adapt the code. This still at an early stage and would require a constant change of code to actually make the new version work. However, this adaptive API layer has undoubtedly saved us a lot of time investigating broken APIs and migrating to new ones.

Some Final Thoughts

Having never developed an iOS application, we have learned a lot about Apple ‘s tool-chain and especially the Swift language. While developing this project, an issue among which also encouraged to make an actual contribution to the apple/swift language on its co-routine implementation. Our team find this year of cooperating with UCL’s X5Learn Team very enjoyable and worthwhile.

Continuous Probability Distributions

posted on 12-03-2020 edited on 14-03-2020

Introduction

Aside from the aforementioned Uniform Distribution, there are many types of distributions for continuous random variables.

The Exponential Distribution

Parameter $ \lambda \quad (\lambda > 0) $

$X \sim Exp(\lambda)$ $c.d.f \quad F(x) = 1 - e^{-\lambda x} \quad (x > 0)$ $p.d.f \quad f(x) = \frac{d F(x)}{dx} = -e^{-\lambda x} \cdot -\lambda = \lambda e^{-\lambda x} \quad (x > 0)$ $\mu = \int_{0}^{\infty} xf(x)dx = \lambda \int_{0}^{\infty} xe^{-\lambda x}dx$ $u = x, \quad v = \frac{e^{-\lambda x}}{-\lambda}$ $\int xe^{-\lambda x}dx = uv - \int u'v = \frac{xe^{-\lambda x}}{-\lambda} - \frac{-1}{\lambda} \int e^{-\lambda x} dx$ $w = -\lambda x, \quad \frac{dw}{dx} = -\lambda, \quad dx = \frac{dw}{-\lambda}$ $\int e^{-\lambda x}dx = \int e^{w} \cdot \frac{dw}{-\lambda} = \frac{1}{-\lambda} e^{w} = \frac{1}{-\lambda} e^{-\lambda x}$ $\int xe^{-\lambda x}dx = \frac{xe^{-\lambda x}}{-\lambda} - \frac{-1}{\lambda} \frac{1}{-\lambda} e^{-\lambda x} = -\frac{xe^{-\lambda x}}{\lambda} - \frac{e^{-\lambda x}}{\lambda^2}$ $\mu = \lambda [-\frac{xe^{-\lambda x}}{\lambda} - \frac{e^{-\lambda x}}{\lambda^2}]_0^\infty = \lambda (0 + \frac{1}{\lambda^2}) = \frac{1}{\lambda}$ $\sigma^2 = \int_{0}^{\infty} x^2f(x) dx - \mu^2 = \lambda \int_{0}^{\infty} x^2 e^{-\lambda x} dx - \frac{1}{\lambda^2}$ $u = x^2, \quad v = \frac{e^{-\lambda x}}{-\lambda}$ $\int x^2 e^{-\lambda x} dx = uv - \int u'v = \frac{x^2 e^{-\lambda x}}{-\lambda} - 2\int x \cdot \frac{e^{-\lambda x}}{-\lambda}dx = \frac{-x^2 e^{-\lambda x}}{\lambda} + \frac{2}{\lambda} \int x \cdot e^{-\lambda x}dx$ $\int x^2 e^{-\lambda x} dx = \frac{-x^2 e^{-\lambda x}}{\lambda} + \frac{2}{\lambda} ( -\frac{xe^{-\lambda x}}{\lambda} - \frac{e^{-\lambda x}}{\lambda^2}) = \frac{-x^2 \cdot e^{-\lambda x}}{\lambda} - \frac{2xe^{-\lambda x}}{\lambda^2} -\frac{2 e^{-\lambda x}}{\lambda^3}$ $\sigma^2 = \lambda [\frac{-x^2 \cdot e^{-\lambda x}}{\lambda} - \frac{2xe^{-\lambda x}}{\lambda^2} -\frac{2 e^{-\lambda x}}{\lambda^3}]^{\infty}_{0} - \frac{1}{\lambda^2} = \lambda (0 + \frac{2}{\lambda^3}) - \frac{1}{\lambda^2} = \frac{1}{\lambda^2}$

The Normal Distribution

Parameter $ \mu, \sigma^2 $

$X \sim N(\mu, \sigma^2)$ $p.d.f \quad f(x) = \frac{1}{\sigma \sqrt{2 \pi}} e^{-\frac{(x - \mu)^2}{2 \sigma^2}}, \quad (-\infty < x < \infty)$ $c.d.f \quad F(x) = \int_{-\infty}^{x} f(x)dx = \int_{-\infty}^{x} \frac{1}{\sigma \sqrt{2 \pi}} e^{-\frac{(x - \mu)^2}{2 \sigma^2}} dx = \frac{1}{\sigma \sqrt{2 \pi}} \int_{-\infty}^{x} e^{\frac{- x^2 + 2\mu x - \mu^2}{2 \sigma^2}}$ $F(x) = \frac{1}{\sigma \sqrt{2 \pi}} \cdot \int_{-\infty}^{x} e^{-\frac{1}{2\sigma^2} x^2} \cdot \int_{-\infty}^{x} e^{\frac{\mu}{\sigma^2} x} \cdot e^{\frac{-\mu^2}{2\sigma^2}} = \frac{1}{\sigma \sqrt{2 \pi}} \cdot \frac{\sqrt{\pi}\sigma \cdot erf(\frac{x}{\sqrt{2}\sigma})}{\sqrt{2}} \cdot \frac{\sigma^2 e^{\frac{\mu x}{\sigma^2}}}{\mu} \cdot e^{\frac{-\mu^2}{2 \sigma^2}}$ $F(x) = \frac{\sigma^2 \cdot erf(\frac{x}{\sqrt{2}\sigma}) \cdot e^{\frac{2\mu x - \mu^2}{2\sigma^2}}}{2\mu}$ $E(X) = \mu$ $Var(X) = \sigma^2$

Central Limit Theorem

The sample mean of a large independent random sample (from any distribution) is approximately normally distributed.

$\bar{X} = \frac{1}{n} \Sigma_{i = 1}^{n} X_i$

$ \bar{X} $ is for large $n$, normal distributed with mean $\mu$ and variance $\frac{\sigma^2}{n}$.

$\Sigma_{i = 1}^{n} X_i \sim N(n\mu, n\sigma^2)$

Standard Normal Distribution

Let $ X \sim N(\mu, \sigma^2) $ and let $ Z = \frac{X - \mu}{\sigma} $

$E(Z) = \frac{1}{\sigma}E(X) - \frac{\mu}{\sigma} = 0$ $Var(Z) = \frac{1}{\sigma^2}Var(X) + 0 = 1$

$ Z \sim N(0, 1) $ is standard normal distribution.

C++ Notes Series (No. 1) Package Principles and Namespaces

posted on 10-03-2020 edited on 12-03-2020

Introduction

In computer programming, package principles are a way of organizing classes in larger systems to make them more organized and manageable. They aid in understanding which classes should go into which packages (package cohesion) and how these packages should relate with one another (package coupling). Package principles also includes software package metrics, which help to quantify the dependency structure, giving different and/or more precise insights into the overall structure of classes and packages.

An important counterpart of which is namespace in C++. CPPReference states that

Namespaces provide a method for preventing name conflicts in large projects.

Symbols declared inside a namespace block are placed in a named scope that prevents them from being mistaken for identically-named symbols in other scopes.

Multiple namespace blocks with the same name are allowed. All declarations within those blocks are declared in the named scope.

Discussion on functions in namespaces or classes

Putting an isolate function in a namespace could be rather a better decision than incorporating it in a class as a method, contradicting to what we have learnt from COMP0004. More specifically, whenever you can implement some functionality efficiently without having to access any private or protected code or data members, you should break it into a free function in the class’s namespace instead of leaving it as a member function. The reason is that by doing so, you keep the class’s interface as small as possible, and thereby reduce the amount of code that potentially needs to be changed if you change the private internals of the class, which is the point of Objective Oriented Programming (OOP) in the first place. Scott Meyers, author of Effective C++, goes into more detail here.

Unfortunately, separating out code that works on T from the class T itself just feels untidy to many programmers raised on the OOP mantra of “Bring code and data together”. But “bringing code and data together” doesn’t actually achieve anything material from a code maintenance or expressiveness point of view — all it gets you is a certain aesthetic appeal, so if you can get past that, you will benefit from the materially better design that comes from keeping class interfaces as small as possible.

If it takes a while to convince yourself that separate functions are actually the Right Thing, don’t feel bad — Meyers’s own first edition of Effective C++ made the same mistake. An example of the C++ Standard Library getting it wrong would be a function like find_first_of() in std::string, which can be implemented with full efficiency without having to know any of the internal details of a std::string — all such a function needs is access to the public functions size() and operator[]().

To end with Scott Meyers own paragraph,

It’s time to abandon the traditional, but inaccurate, ideas of what it means to be object-oriented. Are you a true encapsulation believer? If so, I know you’ll embrace non-friend non-member functions with the fervor they deserve.

Continuous Random Variables VS. Discrete Random Variables (Part 2)

posted on 25-02-2020 edited on 12-03-2020

Continuous Distributions

Uniform Distribution

$X \sim U(a, b)$

This indicates that all outcomes from interval $(a, b)$ are equally likely.

$f(x) = \frac{1}{b - a} \quad \forall a < x < b$ $f(x) = 0 \quad (otherwise)$ $F(x) = 0 \quad \forall a \leq x$ $F(x) = \frac{x - a}{b - a} \quad \forall a < x < b$ $F(x) = 1 \quad \forall x \leq b$ $E(X) = \int^b_a x \frac{1}{b - a}dx = [\frac{x^2}{2(b - a)}]^b_a = \frac{b^2 - a^2}{2(b - a)} = \frac{a + b}{2}$ $Var(X) = \int^b_a x^2 \frac{1}{b - a}dx - E(X)^2 = [\frac{x^3}{3(b - a)}]^b_a - E(X)^2 = \frac{b^3 - a^3}{3(b - a)} - E(X)^2$ $= \frac{(b - a)(b^2 + ab + a^2}{3(b - a)} - E(X)^2 = \frac{b^2 + ab + a^2}{3} - \frac{a^2 + b^2 + 2ab}{4}$ $= \frac{4b^2 + 4ab + 4a^2 - 3a^2 - 3b^2 - 6ab}{12} = \frac{a^2 - 2ab + b^2}{12} = \frac{(a - b)^2}{12}$

Possible Usage: as a starting point in simulations, if we can generate a random number in $U(0, 1)$, we can arbitrarily expand the range to almost any other uniform distribution

Continuous Random Variables VS. Discrete Random Variables (Part 1)

posted on 24-02-2020 edited on 12-03-2020

Concept

Discrete random variable : countable number of possible values
Continuous random variable : uncountably (infinite) number of possible values
The cumulative distribution function of a variable $X$ is the function

$F(x) = P(X \leq x) \quad \forall x \in R$

The probability density function of a variable $X$ is the function

$f(x) = \frac{dF(x)}{dx}$

A given point on $f(x)$ should not be interpreted as $f(x) = P(X = x)$. It should be an analogy to density, or change of probability rate at $x$.

Properties for $f(x)$,

$f(x) \geq 0, \forall x \in R $
$\int_a^b f(x) dx = [F(x)]_a^b = F(b) - F(a) = P(a < X \leq B) $
$\int_{-\infty}^{\infty}f(x) dx = P(-\infty < X \leq + \infty) = 1 $

Population Mean

$\mu = E(X) = \int_{-\infty}^{\infty} xf(x) dx$ $\sigma^2 = Var(X) = E[X^2] - E[X]^2 = \int_{-\infty}^{\infty} x^2 f(x)dx - \mu^2$

For any transformation made on $x$, let $g(x)$

$E(g(x)) = \int_{-\infty}^{\infty} g(x)f(x) dx$

Two continuous random variables $X$ and $Y$ are independant

$\iff P(X = x_i, Y = y_j) = P(X = x_i) \cdot P(Y = y_j) \quad \forall x_i, y_j$

Example

Given a unit circle marked with $0, 1, 2, 3$ at $\theta = 0, \frac{\pi}{2}, \pi, \frac{3\pi}{2}$ respectively. The circumference of the unit circle has value range from $0 \leq Y < 4$.

A pointer from the origin with length of $1$ is spun and is equally likely to stop anywhere on the circle. Let $Y$ be the value obtained from the circle.

$Y$ is a continuous random variable.

$P(Y \leq 1) = \frac{1}{4}$ $P(Y \leq 2) = \frac{1}{2}$ $P(3 < Y \leq 3.5) = \frac{1}{8}$

In the example above

$F(y) = 0 \; (y < 0), \quad F(y) = \frac{y}{4} \; (0 \leq y < 4), \quad F(y) = 1 \; (4 \leq y)$ $f(y) = F'(y) = \frac{1}{4} \; (0 \leq y < 4)$ $\mu = \int_{0}^{4} y \cdot \frac{1}{4} = [\frac{1}{8}y^2]_0^4 = 2$ $\sigma^2 = \int_{0}^{4} \cdot y^2 \frac{1}{4} - 2^2= [\frac{1}{12}y^3]_0^4 - 4 = \frac{4}{3}$

In the next post, we will be looking at continuous distributions, as similar to discrete distributions in previous posts here, part 1 and here, part 2.

C++ Notes Series (No. 0)

posted on 23-02-2020 edited on 12-03-2020

Introduction

Hi, I have decided to start a series to blog post to enrich my blog content and also, share several insights of myself when learning C++, especially modern C++ features.

I have made a list below on possible features I am looking at to write in this series.

Pointers and Smart Pointers
Classes, Structs, Constructors, Destructors, Copy Constructors
More on OOP: Inheritance, Virtual Functions, Interfaces, Visibility
STLs
Macros and Lambdas
Namespaces
Threads, Concurrency features
Design Patterns: Singletons, Factories
Move semantics, Rvalue References, Forwarding References, auto keyword
Maps and Sets Splicing
Parallel Algorithms in C++17

This is the content list for the moment, and I believe this will keep me busy for a while. However, if there is something specific you want to see, please don’t hesitate to drop me an email at patrick.wu (at) linux.com .

Exploring Flask Authentication Methods Part 2

posted on 13-02-2020 edited on 12-03-2020

Continued

Last time we talked about CSRF tokens. So what is CSRF?

Cross-Site Request Forgery

Well, Wikipedia has a brief explanation of how it works. In short,

Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.

There are many ways to utilise CSRF on unprotected websites. However, this can be largely prevented by providing the user with a csrf_token only when they logging in on the valid website, and storing them in sessions.

Solution

My final solution to this problem, in the Swift code below, is to use a web request to get a csrf_token and then login with a valid user request.

static func fetchCSRFToken () -> String {
    var csrfToken = ""
    let semaphore = DispatchSemaphore(value: 0)
    let task = URLSession.shared.dataTask(with: URL.init(string: newAdapter.generateLoginQueryURL())!) {(data, response, error) in
        defer { semaphore.signal() }
        guard let data = data else { return }
        do {
            let divFields: Elements = try SwiftSoup.parse(String(decoding: data, as: UTF8.self)).body()!.select("div")
            let centreDiv = divFields.array()[1]
            let inputFields = try centreDiv.select("form").first()!.select("input")
            for inputField in inputFields {
                if inputField.id() == "csrf_token" {
                    csrfToken = try inputField.val()
                }
            }
        } catch {
            print("error: cannot fetch csrf token")
        }
    }
    task.resume()
    semaphore.wait()
    if (csrfToken == "") {
        fatalError("error: cannot fetch csrf token")
    } else {
        return csrfToken
    }
}

Afterwards, generate a POST request in JSON style (e.g. {email: "[email protected]", password:"pwd", csrf_token:"token"}) and post it to your designated flask-security login endpoint. You will get a response with your authentication token. From then on, use this authentication token for future requests.

What’s more?

Authentication tokens should have a valid lifetime and re-authenticate from time to time to ensure better security. We have yet to come up with a solution to modify flask-security‘s internal mechanisms to realise this feature.

Regarding the HTTP request, we are planning to adapt to Alamofire for more elegant network solutions.

For more information, checkout

Wikipedia - Cross-site Request Forgery
CSRF Protection - Flask

Statistical Distributions (Part 2)

posted on 12-02-2020 edited on 15-03-2020

Poisson Distribution (Continued)

As stated in the previous post,

Let

$\lambda = n \cdot p$ $Binomial(n, p) \approx Poisson(n p) = Poisson(\lambda)$

For Binomial Distribution,

$P(x) = C_n^x p^x q^{n-x} = C_n^x \cdot (\frac{\lambda}{n})^x \cdot (1 - \frac{\lambda}{n})^{n -x}$

Thus,

$\lim_{n \rightarrow \infty} P(x) = \lim_{n \rightarrow \infty} \frac{n \cdot (n - 1) ... \cdot (n - x + 1)}{x!} \cdot \frac{\lambda^x}{n^x} \cdot (1 - \frac{\lambda}{n})^n \cdot (1 - \frac{\lambda}{n})^{-x}$ $= \lim_{n \rightarrow \infty} \frac{n \cdot (n - 1) ... \cdot (n - x+ 1)}{n^x} \cdot \frac{\lambda^x}{x !} \cdot \lim_{n \rightarrow \infty} (1 - \frac{\lambda}{n})^n (1 - \frac{\lambda}{n})^{-x}$ $= 1 \cdot \frac{\lambda^x}{x!} \cdot e^{-\lambda} \cdot 1 = e^{-\lambda} \cdot \frac{\lambda^k}{k!}$

The positive real number $\lambda$ is equal to the expected value and also its variance.

$\lambda = \mu = \sigma^2$

Gaussian Distribution (Normal Distribution)

Probability Density Function

Given $\mu = E(X)$ and $\sigma^2 = Var(X)$ ,

$f(x \mid \mu, \sigma^2) = \frac{1}{\sqrt{2\pi\sigma^2}} \; e^{-\frac{(x-\mu)^2}{2\sigma^2}}$

A standard normal distribution follows $\mu = 1$ and $\sigma^2 = 1$

Cumulative Distribution Function

Cumulative Distribution Function, or $F(x)$ is the probability that $X \leq x$ .

$F(x \mid \mu, \sigma^2) = \frac{1}{\sqrt{2\pi \sigma^2}} \int_{-\infty}^{x} e^{-\frac{(t-\mu)^2}{2\sigma^2}}dt$

static_cast

Format:

const_cast

Format:

reinterpret_cast

Format:

Introduction

Motivation: Completion handlers are suboptimal

Problem 1: Pyramid of doom

Problem 2: Error handling

Problem 3: Conditional execution is hard and error-prone

Problem 4: Many mistakes are easy to make

Problem 5: Because completion handlers are awkward, too many APIs are defined synchronously

Problem 6: Other “resumable” computations are awkward to define

Proposed Solution: Coroutines

Async semantics

Entering and leaving async code

Conversion of imported Objective-C APIs

Interaction with existing features

Error handling

Closure type inference

defer and abandonment

Completion handlers with multiple return values

Source Compatibility

Effect on ABI stability

Alternate Syntax Options

Spelling of async keyword

Make async be a subtype of throws instead of orthogonal to it

Make async default to throws

Behavior of beginAsync and suspendAsync operations

Alternatives Considered

Include Future or other coordination abstractions in this proposal

Have async calls always return a Future

Have a generalized “do notation” for monadic types

Potential Future Directions

New Foundation, GCD, and Server APIs

Documentation

rethrows could be generalized to support potentially async operations

Blocking calls

Fix queue-hopping Objective-C completion handlers

Thanks

About Us

What have we been working on?

What are the technical challenges?

How did we solve them?

Some Final Thoughts

Introduction

The Exponential Distribution

The Normal Distribution

Central Limit Theorem

Standard Normal Distribution

Introduction

Discussion on functions in namespaces or classes

Continuous Distributions

Uniform Distribution

Concept

Example

Next

Introduction

Contents

Continued

Cross-Site Request Forgery

Solution

What’s more?

More

Poisson Distribution (Continued)

Gaussian Distribution (Normal Distribution)

Probability Density Function

Cumulative Distribution Function

`static_cast`

`const_cast`

`reinterpret_cast`

`defer` and abandonment

Spelling of `async` keyword

Make `async` be a subtype of `throws` instead of orthogonal to it

Make `async` default to `throws`

Behavior of `beginAsync` and `suspendAsync` operations

Include `Future` or other coordination abstractions in this proposal

Have async calls always return a `Future`

`rethrows` could be generalized to support potentially `async` operations