6 Types✎

What a pin's type is, the five families every type falls into, which pins connect, and where types come from.

Normative · Level 2Draft 0.1Pending review

6.1 Pin types, abstractly

A flow pin has no type. A data pin has one, written as a name: the profile's name for it, such as number or Model.
Two names are the same in every profile: any, which holds anything, and pair, a key and its value, which exists only to build a dictionary.
Whether a value may be missing is not part of the type. A pin MAY be marked as possibly missing, which does not change what connects.
A node MAY work out a pin's type from its other pins or settings, such as a node that makes an object of a class it is told, whose output is then that class. A reroute knot takes the type of what feeds it.
A node MAY let a person choose the type of an input it declares as any.

6.1-R1

A renderer SHOULD say where it shows a pin's type that its value may be missing. Roswaal writes Model?.

Roswaal does in a pin's tooltip and the Inspector, and not yet on its type chip.

Roswaal partly

6.1-R2

Choosing the type of an any input narrows what can be wired and typed in, and MUST NOT change the program.

Roswaal meets

6.2 Families

Every type belongs to exactly one of five families, which decide the shape its pin is drawn in (§5.5).

6.2-R1

A profile MUST put each of its types in one family, and MUST NOT add a family.

Roswaal meets

Family	Drawn as	Holds
`value`	circle	A plain value: a number, a string, a Vector3
`object`	rounded square	A thing in the game: an Instance or any class
`table`	diamond	A table, an array or a dictionary
`function`	dot in a ring	A function, to call or to pass along
`signal`	hexagon	Something to listen to: an event

Generated from core/typeFamily.ts.

Anything untyped, generic or unknown is a value: the circle is the shape that claims nothing. Families are for reading. They take no part in what connects.

6.3 Connecting pins

A wire joins an output to an input of the same kind: flow to flow, data to data. Any flow output may lead to any flow input. A data output may lead to a data input when the first rule that applies says so:

If either side is pair, they connect only when both are, or when the input is marked as taking pairs.
A pin with no type counts as any.
The same type connects.
any connects in either direction.
Two types connect where the profile says the language converts one into the other by itself. In the Luau profiles: number and string, both ways.
A subtype connects into its supertype, by the profile's hierarchy (§10.3). The other way does not: narrowing needs a cast, which is a node of its own.
Nothing else connects.

From	To	Connects	Shows
`number`	`number`	Yes	the same type
`any`	`Model`	Yes	`any` connects to anything
`Vector3`	`any`	Yes	and anything to `any`
`number`	`string`	Yes	a conversion the language makes by itself
`string`	`number`	Yes	in either direction
`Model`	`Instance`	Yes	a subtype into its supertype
`Instance`	`Model`	No	but not the other way: a cast narrows it
`boolean`	`number`	No	two unrelated types
`pair`	`pair`	Yes	a key and value pair, into a pair input
`pair`	`any`	No	a pair goes nowhere else, not even `any`

Generated: each row's answer is pinsCompatible in core/compiler/validate.ts, run on that pair as these pages are built. Model and Instance are the Roblox profile's.

6.3-R1

An editor MUST refuse to make a wire this rule does not allow, and SHOULD say why.

Roswaal refuses every one, and says why only when a class cannot be narrowed without a cast.

Roswaal partly

6.3-R2

A compiler MUST report a wire between a flow pin and a data pin as an error, and SHOULD report a data wire this rule does not allow, which can arrive in a file written elsewhere, as a warning.

Roswaal meets

6.3-R3

A wire between two types the rule joins through a conversion SHOULD be drawn so the change shows (§5.6).

Roswaal meets

6.4 Types from source code

A graph can call functions written in another graph of the same project, and its pins take their types from that graph's declarations: a parameter becomes an input of its type, a result an output. A profile says how its language's own type annotations become pin types (§10.3), and a type the profile cannot express as a pin type becomes any.

Not yet in Roswaal

Functions in hand-written source files, rather than in graphs, do not give pins types yet; their doc comments feed the code editor's hover and completion only.

6.5 Tags in comments

Proposed, not built

A way to type a hand-written function's pins from tags in its doc comments, written so that a documentation generator that does not know them ignores them. For Luau the design has to keep Moonwave sites building: Moonwave treats an unknown tag in a doc comment as an error, so these tags would live in plain -- comments, which Moonwave skips. §11.9 will carry the Luau form when it is decided.

6.6 What a profile must add

Its type names, and the family of each (§6.2).
Its conversions: which types connect because the language converts between them by itself, and nothing the language would need asked to do.
Its hierarchy, if the language has subtypes, as a parent for each type.
How each of its language's type annotations becomes a pin type.
A colour for each type it wants told apart at a glance, and a short name for any whose full name is too long for a chip (§5.5).

The Roblox profile's families, for example: Model is an object, RBXScriptSignal a signal, table a table.

Not reviewed yet