Skip to content

Commit d6ba326

Browse files
authored
Require semicolons after package too (#257)
This is a follow-up to #249 and discussion in today's component model meeting to require semicolons after the `package` statement to ensure it's consistent with all other "single line things" in the WIT format.
1 parent 9fde369 commit d6ba326

File tree

1 file changed

+36
-36
lines changed

1 file changed

+36
-36
lines changed

design/mvp/WIT.md

Lines changed: 36 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -46,13 +46,13 @@ Package identifiers are specified at the top of a WIT file via a `package`
4646
declaration:
4747

4848
```wit
49-
package wasi:clocks
49+
package wasi:clocks;
5050
```
5151

5252
or
5353

5454
```wit
55-
package wasi:clocks@1.2.0
55+
package wasi:clocks@1.2.0;
5656
```
5757

5858
WIT packages can be defined in a collection of files and at least one of them
@@ -74,7 +74,7 @@ belong to an interface.
7474
An example of an interface is:
7575

7676
```wit
77-
package local:demo
77+
package local:demo;
7878
7979
interface host {
8080
log: func(msg: string);
@@ -98,7 +98,7 @@ An `interface` can contain [`use`][use] statements, [type][types] definitions,
9898
and [function][functions] definitions. For example:
9999

100100
```wit
101-
package wasi:filesystem
101+
package wasi:filesystem;
102102
103103
interface types {
104104
use wasi:clocks.wall-clock.{datetime};
@@ -135,7 +135,7 @@ equivalent of a `component` type in the component model. For example this
135135
world:
136136

137137
```wit
138-
package local:demo
138+
package local:demo;
139139
140140
world my-world {
141141
import host: interface {
@@ -165,7 +165,7 @@ Worlds can contain any number of imports and exports, and can be either a
165165
function or an interface.
166166

167167
```wit
168-
package local:demo
168+
package local:demo;
169169
170170
world command {
171171
import wasi:filesystem/filesystem;
@@ -187,7 +187,7 @@ Additionally interfaces can be defined inline with an explicit kebab-name that
187187
avoids the need to have an out-of-line definition.
188188

189189
```wit
190-
package local:demo
190+
package local:demo;
191191
192192
interface out-of-line {
193193
the-function: func();
@@ -209,7 +209,7 @@ In the component model imports to a component either use an ID or a
209209
kebab-name, and in WIT this is reflected in the syntax:
210210

211211
```wit
212-
package local:demo
212+
package local:demo;
213213
214214
interface my-interface {
215215
// ..
@@ -243,7 +243,7 @@ A World can be created by taking the union of two or more worlds. This operation
243243
Below is a simple example of a world that includes two other worlds.
244244

245245
```wit
246-
package local:demo
246+
package local:demo;
247247
248248
// definitions of a, b, c, foo, bar, baz are omitted
249249
@@ -283,7 +283,7 @@ world union-my-world {
283283
The `include` statement also works with [WIT package](#wit-packages-and-use) defined below with the same semantics. For example, the following World `union-my-world-a` is equivalent to `union-my-world-b`:
284284

285285
```wit
286-
package local:demo
286+
package local:demo;
287287
288288
interface b { ... }
289289
interface a { ... }
@@ -313,7 +313,7 @@ world union-my-world-b {
313313
If two worlds shared the same set of import and export IDs, then the union of the two worlds will only contain one copy of this set. For example, the following two worlds `union-my-world-a` and `union-my-world-b` are equivalent:
314314

315315
```wit
316-
package local:demo
316+
package local:demo;
317317
318318
world my-world-a {
319319
import a1;
@@ -342,7 +342,7 @@ When two or more included Worlds have the same name for an import or export that
342342
The following example shows how to resolve name conflicts where `union-my-world-a` and `union-my-world-b` are equivalent:
343343

344344
```wit
345-
package local:demo
345+
package local:demo;
346346
347347
world world-one { import a: func(); }
348348
world world-two { import a: func(); }
@@ -361,7 +361,7 @@ world union-my-world-b {
361361
`with` cannot be used to rename IDs, however, so the following world would be invalid:
362362

363363
```wit
364-
package local:demo
364+
package local:demo;
365365
366366
interface a {
367367
foo: func();
@@ -403,7 +403,7 @@ A `use` statement inside of an `interface` or `world` block can be used to
403403
import types:
404404

405405
```wit
406-
package local:demo
406+
package local:demo;
407407
408408
interface types {
409409
enum errno { /* ... */ }
@@ -425,7 +425,7 @@ Interfaces linked with `use` must be acyclic.
425425
Names imported via `use` can be renamed as they're imported as well:
426426

427427
```wit
428-
package local:demo
428+
package local:demo;
429429
430430
interface my-host-functions {
431431
use types.{errno as my-errno};
@@ -447,7 +447,7 @@ interface types {
447447
}
448448
449449
// host.wit
450-
package local:demo
450+
package local:demo;
451451
452452
interface my-host-functions {
453453
use types.{errno, size};
@@ -462,7 +462,7 @@ the same syntax is used in `import` and `export` directives:
462462

463463
```wit
464464
// a.wit
465-
package local:demo
465+
package local:demo;
466466
467467
world my-world {
468468
import host;
@@ -484,7 +484,7 @@ When referring to an interface an ID form can additionally be used to refer to
484484
dependencies. For example above it was seen:
485485

486486
```wit
487-
package local:demo
487+
package local:demo;
488488
489489
world my-world {
490490
import wasi:clocks/monotonic-clock;
@@ -497,7 +497,7 @@ This is the package identified by `wasi:clocks` and the interface
497497
well:
498498

499499
```wit
500-
package local:demo
500+
package local:demo;
501501
502502
interface my-interface {
503503
use wasi:http/types.{request, response};
@@ -510,7 +510,7 @@ If a package being referred to has a version number, then using the above syntax
510510
so far it can get a bit repetitive to be referred to:
511511

512512
```wit
513-
package local:demo
513+
package local:demo;
514514
515515
interface my-interface {
516516
use wasi:http/types@1.0.0.{request, response};
@@ -528,7 +528,7 @@ interfaces within the scope of the file itself. For example the above could be
528528
rewritten as:
529529

530530
```wit
531-
package local:demo
531+
package local:demo;
532532
533533
use wasi:http/types@1.0.0;
534534
use wasi:http/handler@1.0.0;
@@ -550,7 +550,7 @@ The interface referred to by a `use` is the name that is defined in the current
550550
file's scope:
551551

552552
```wit
553-
package local:demo
553+
package local:demo;
554554
555555
use wasi:http/types; // defines the name `types`
556556
use wasi:http/handler; // defines the name `handler`
@@ -560,7 +560,7 @@ Like with interface-level-`use` the `as` keyword can be used to rename the
560560
inferred name:
561561

562562
```wit
563-
package local:demo
563+
package local:demo;
564564
565565
use wasi:http/types as http-types;
566566
use wasi:http/handler as http-handler;
@@ -570,7 +570,7 @@ Note that these can all be combined to additionally import packages with
570570
multiple versions and renaming as different identifiers.
571571

572572
```wit
573-
package local:demo
573+
package local:demo;
574574
575575
use wasi:http/types@1.0.0 as http-types1;
576576
use wasi:http/types@2.0.0 as http-types2;
@@ -589,7 +589,7 @@ component.
589589
For example this document:
590590

591591
```wit
592-
package local:demo
592+
package local:demo;
593593
594594
interface shared {
595595
record metadata {
@@ -646,7 +646,7 @@ Functions are defined in an [`interface`][interfaces] or are listed as an
646646
be named and have unique names:
647647

648648
```wit
649-
package local:demo
649+
package local:demo;
650650
651651
interface foo {
652652
a1: func();
@@ -658,7 +658,7 @@ interface foo {
658658
Functions can return at most one unnamed type:
659659

660660
```wit
661-
package local:demo
661+
package local:demo;
662662
663663
interface foo {
664664
a1: func() -> u32;
@@ -669,7 +669,7 @@ interface foo {
669669
And functions can also return multiple types by naming them:
670670

671671
```wit
672-
package local:demo
672+
package local:demo;
673673
674674
interface foo {
675675
a: func() -> (a: u32, b: float32);
@@ -688,7 +688,7 @@ time. The types supported in WIT is the same set of types supported in the
688688
component model itself:
689689

690690
```wit
691-
package local:demo
691+
package local:demo;
692692
693693
interface foo {
694694
// "package of named fields"
@@ -867,7 +867,7 @@ WIT files optionally start with a package declaration which defines the ID of
867867
the package.
868868

869869
```ebnf
870-
package-decl ::= 'package' ( id ':' )+ id ( '/' id )* ('@' valid-semver)?
870+
package-decl ::= 'package' ( id ':' )+ id ( '/' id )* ('@' valid-semver)? ';'
871871
```
872872

873873
The production `valid-semver` is as defined by
@@ -1406,7 +1406,7 @@ An example of the binary format is that this document:
14061406

14071407
```wit
14081408
// host.wit
1409-
package local:demo
1409+
package local:demo;
14101410
14111411
interface console {
14121412
log: func(arg: string);
@@ -1434,7 +1434,7 @@ This is done to implement `use` statements:
14341434

14351435
```wit
14361436
// host.wit
1437-
package local:demo
1437+
package local:demo;
14381438
14391439
interface types {
14401440
enum level {
@@ -1479,7 +1479,7 @@ A `world` is represented as a component type.
14791479

14801480
```wit
14811481
// host.wit
1482-
package local:demo
1482+
package local:demo;
14831483
14841484
world the-world {
14851485
export test: func();
@@ -1509,7 +1509,7 @@ the parts needed, within the component:
15091509

15101510
```wit
15111511
// host.wit
1512-
package local:demo
1512+
package local:demo;
15131513
15141514
world the-world {
15151515
import console;
@@ -1546,7 +1546,7 @@ type as well.
15461546

15471547
```wit
15481548
// foo.wit
1549-
package local:demo
1549+
package local:demo;
15501550
15511551
interface foo {
15521552
use wasi:http/types.{some-type};
@@ -1590,7 +1590,7 @@ interface handler {
15901590
}
15911591
15921592
// wit/proxy.wit
1593-
package wasi:http
1593+
package wasi:http;
15941594
15951595
world proxy {
15961596
import wasi:logging/backend;

0 commit comments

Comments
 (0)