-
Lower the barrier of entry to adopting and understanding TypeScript. North star.
-
Understand the TypeScript Codebase enough to provide useful API documentation and fix bugs. Validated by having a more comprehensive set of tools for people to understand how the language and tooling works.
-
Make contributing to TypeScript easier, and reduce the amount of work maintainers need to do. Validated probably by the number of open PRs, and the number of external contributors per release.
-
Make it easier to people wanting to build tooling around TypeScript. Validated by seeing more usage of tools like the community discord, people shipping tools with TypeScript support by default etc.
let xs = [1, 2, 3, 4, 5] | |
for (element, index) in zip(xs, xs.indices) { | |
if index == xs.startIndex { | |
print("START") | |
} | |
print(element) | |
if index == xs.index(before: xs.endIndex) { |
import Foundation | |
import Ink | |
func tidy(_ inputStr: String) -> String { | |
let task = Process() | |
task.launchPath = "/usr/local/Cellar/tidy-html5/5.6.0/bin/tidy" | |
task.arguments = ["--show-body-only", "yes", "--show-info", "no", "--show-warnings", "no", "--show-errors", "0"] | |
let input = Pipe() | |
let output = Pipe() |
import ContactTracing | |
extension CTExposureDetectionSession { | |
func addPositiveDiagnosisKeys(batching keys: [CTDailyTracingKey], completion: CTErrorHandler) { | |
if keys.isEmpty { | |
completion(nil) | |
} else { | |
let cursor = keys.index(keys.startIndex, offsetBy: maxKeyCount, limitedBy: keys.endIndex) ?? keys.endIndex | |
let batch = Array(keys.prefix(upTo: cursor)) | |
let remaining = Array(keys.suffix(from: cursor)) |
import Foundation | |
enum LexingError: Error, Equatable { | |
case syntaxError(String) | |
case unexpectedEOF | |
} | |
enum ParsingError: Error { | |
case expected(String) | |
case unexpectedToken(Token) |
/*: | |
Joe Groff: | |
> In a lot of the ways people use dictionaries/maps/hashtables, there's a type dependency between | |
> the keys and values, but most mainstream typed languages provide homogeneously-typed maps. | |
> Are there any that try to preserve more interesting type relationships between key and value? | |
> https://twitter.com/jckarter/status/1278739951568314368 | |
> As one example, it's common for specific keys to be associated with specific types, like in | |
> {"name": "Tanzy", "age": 13}, "name" should always map to a string, and "age" to a number. |
#import <Foundation/Foundation.h> | |
@interface JNWThrottledBlock : NSObject | |
// Runs the block after the buffer time _only_ if another call with the same identifier is not received | |
// within the buffer time. If a new call is received within that time period the buffer will be reset. | |
// The block will be run on the main queue. | |
// | |
// Identifier and block must not be nil. | |
+ (void)runBlock:(void (^)())block withIdentifier:(NSString *)identifier throttle:(CFTimeInterval)bufferTime; |
static UIImage * UIImageForSwatchOfColorWithSize(UIColor *color, CGSize size) { | |
UIImage *image = nil; | |
CGRect rect = CGRectMake(0.0f, 0.0f, size.width, size.height); | |
UIGraphicsBeginImageContext(rect.size); | |
{ | |
CGContextRef c = UIGraphicsGetCurrentContext(); | |
CGContextSetFillColorWithColor(c, [color CGColor]); |
@import MobileCoreServices; | |
static CFStringRef UTTypeForImageData(NSData *data) { | |
const unsigned char * bytes = [data bytes]; | |
if (data.length >= 8) { | |
if (bytes[0] == 0x89 && bytes[1] == 0x50 && bytes[2] == 0x4E && bytes[3] == 0x47 && bytes[4] == 0x0D && bytes[5] == 0x0A && bytes[6] == 0x1A && bytes[7] == 0x0A) { | |
return kUTTypePNG; | |
} | |
} |
Hello, I’ve been working on implementing, optimizing, and improving String in preparation for ABI stability, and I thought I’d share the current status of String in Swift 5 and some potential directions to go. This is the product of conversations with open source contributors and my colleagues on the Swift standard library team at Apple.
The primary area of focus is stabilizing String’s ABI, but we’d be remiss if we couldn’t also fit in performance and ergonomic improvements. String’s ergonomics in particular is one area where we think the status quo is woefully inadequate, and over half of this email is devoted to that topic. At the end, there’s a section about a community initiative that we hope can help users of String as well as guide future development.
(Note: I’m sending this to swift-dev because much of the contents revolve around implementation concerns. I’ll also cross-reference on swift-evolution and swift-users. See also the [StringManife