| #include <stdio.h> | |
| #include <stdlib.h> | |
| #include <stdint.h> | |
| #ifdef _MSC_VER | |
| #include <intrin.h> /* for rdtscp and clflush */ | |
| #pragma optimize("gt",on) | |
| #else | |
| #include <x86intrin.h> /* for rdtscp and clflush */ | |
| #endif |
Данный FAQ был специально создан для телеграм сообщества https://t.me/WebAssembly_ru.
Он базируется на статье от Andre Weissflog, но так же содержит множество моих дополнений и мыслей, которые могут быть уже не слишком актуальны на момент прочтения. Прошу это учитывать.
| /* | |
| A collection of tests where Flow and TypeScript might have different behavior | |
| Some tests are borrowed from https://github.com/vkurchatkin/typescript-vs-flow | |
| Some tests now have the same behavior as the new versions of Flow/TS have fixed the bugs and improved type safety | |
| */ | |
| /* 1. Accessing unknown properties on objects */ |
Decorators are a proposal for extending JavaScript classes which is widely adopted among developers in transpiler environments, with broad interest in standardization. TC39 has been iterating on decorators proposals for over five years. This document describes a new proposal for decorators based on elements from all past proposals.
Decorators @decorator are functions called on class elements or other JavaScript syntax forms during definition, potentially wrapping or replacing them with a new value returned by the decorator.
A decorated class field is treated as wrapping a getter/setter pair for accessing that storage. Decorated storage is useful for observation/tracking, which has been a pain point for the original legacy/experimental decorators combined with [[Define]] semantics for class fields. These semantics are based on Michel Weststrate's "trapping decorators" proposal.