luau-lang/luau
1
0
Fork 0
mirror of https://github.com/luau-lang/luau.git synced 2025-05-04 10:33:46 +01:00
Code Issues Projects Releases Packages Wiki Activity

Fixing typos

Browse source
This commit is contained in:
ajeffrey@roblox.com 2022-01-04 15:08:24 -06:00
parent 436ebff11c
commit 7c4508e6e5
1 changed files with 3 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
rfcs/api-evolution.md
View file

@ -23,7 +23,6 @@ In order to avoid breaking changes, we need to know what they are!
In this RFC, we follow the [Rust API Evolution](https://rust-lang.github.io/rfcs/1105-api-evolution.html) In this RFC, we follow the [Rust API Evolution](https://rust-lang.github.io/rfcs/1105-api-evolution.html)
guidelines, which build on the [Semantic Versioning](https://semver.org/) specification. guidelines, which build on the [Semantic Versioning](https://semver.org/) specification.
This RFC is just about *API changes* not *behavioral changes* (which are important but out of scope). This RFC is just about *API changes* not *behavioral changes* (which are important but out of scope).
Changes are tracked in versions, and are either:
From the Rust API evolution guidelines, changes are classified as: From the Rust API evolution guidelines, changes are classified as:
@ -188,7 +187,7 @@ module, we know there are no additional properties, but not externally:
function exports.new() : Point return { x=0, y=0 } end function exports.new() : Point return { x=0, y=0 } end
``` ```
User code cannot construct `Points` directly, and rely on exported User code cannot construct `Point`s directly, and relies on exported
factory methods. They do have access to the properties though: factory methods. They do have access to the properties though:
```lua ```lua
@ -203,7 +202,7 @@ The subtyping rules for an opaque type:
export type t<as> = { ps : Ts, ... } export type t<as> = { ps : Ts, ... }
``` ```
are(using `{| ps : Ts |}` for unsealed tables and `{ ps : Ts }` for sealed tables): are (using `{| ps : Ts |}` for unsealed tables and `{ ps : Ts }` for sealed tables):
* within the defining module, `{| ps : Ts[Us/as] |}` is a subtype of `t<Us>`, and * within the defining module, `{| ps : Ts[Us/as] |}` is a subtype of `t<Us>`, and
* anywhere, `t<Us>` is a subtype of `{ ps : Ts[Us/as] }`. * anywhere, `t<Us>` is a subtype of `{ ps : Ts[Us/as] }`.
@ -336,7 +335,7 @@ There are the usual bike-shedding options for syntax, in particular
we could use attributes rather than new syntax for `...` and `...?`. we could use attributes rather than new syntax for `...` and `...?`.
We could allow other privacy modifiers, for example declaring some We could allow other privacy modifiers, for example declaring some
properties private, or allowing pasckage-level privacy scope as well properties private, or allowing package-level privacy scope as well
as module-level. as module-level.
We could add extra subtyping rules for opaque types, for example We could add extra subtyping rules for opaque types, for example