Add interfaces as a proof-of-concept experimental feature #10181

0x6e · 2025-11-29T16:38:15Z

Proof of concept for #1870.

Introduce a new keyword interface which allows a user to declare an interface. This follows the same rules as a global. An interface cannot have:

sub elements;
repeated elements;
property animations;
states;
transitions;
an init callback declaration;
an init callback implementation.

Introduce a new keyword implements which allows a user to declare that a component implements an interface. This initial implementation simply copies the interface property declarations into the component.

Introduce a new keyword uses which allows a user to declare that a parent component implements an interface through a child component. This initial implementation creates two way property bindings between the parent component and the child for each property in the interface.

This PR only deals with simple property declarations. Future PRs will be needed to:

expand the tests for interface properties;
add support for callbacks;
add support for functions;
add support for components that implement an interface and inherit from a base component;
add support for components to implement more than one interface;
allow interfaces to inherit other interfaces.

Add a new ElementType variant that will allow us to parse interface declarations using the existing element parsing code. The match arms implemented are my best guess based on the context of the enclosing function and how a global is handled.

A document may contain zero or more interfaces. Interfaces do not support inheritance.

Verify that an interface cannot have: - sub elements; - repeated elements; - property animations; - states; - transitions; - an init callback declaration; - an init callback implementation.

Warn if private properties are declared.

It is treated as an alias for `inherits`, for now.

The compiler produces an error when the `implements` keyword is used before a global, component, or builtin type. The parser doesn't know about this kind of relationship - the "implements" and "inherits" keywords are just consumed. For now we just go back and check what the expected relationship type was whilst constructing an Element.

Attempt to verify that the interpreter can see and use properties declared in an interface that a component implements. This is an initial proof-of-concept, we will need to come back and add checks and tests for mixing 'inherits' with 'implements'.

Group interface related tests in a subdirectory of their own.

Allow a new component to specify that it exposes one or more interfaces via a given child element. This commit introduces the syntax, we will add the implementation in a future commit.

For each uses statement, iterate through the interface properties and create two-way bindings to the property on the specified base component. The error cases will be populated in follow-up commit. For now, demonstrate that the initial concept works.

Detect and emit errors where: - the type specified in a uses statement is not an interface; - the type specified in a uses statement is unknown; - the type specified in a uses statement cannot be used in this context.

…does not exist Add a test case to verify the expected error message.

Add a test to verify that interfaces from imported modules can be used.

Add a test case to verify that: - we can import an interface as another name and re-use it; - we can import a component that implements a renamed interface and use it.

For each property in an interface that a child element is expected to implement, verify that the child has a property with the same name, type and visibility. This is easier than attempting to store and match interface names which may change if the user renames an interface when importing.

Emit a compile error if the user attempts to declare a property that would override a property from an interface.

…an inherited property Look up the interface property on the base type before allowing a component to implement the interface.

…xisting binding I couldn't figure out a good way to test this - everything I came up with got caught by the prior check that the property does not already exist.

Guard these keywords behind the experimental features flag. Slint must be compiled with the `SLINT_ENABLE_EXPERIMENTAL_FEATURES` environment variable set to enable these keywords.

0x6e · 2025-11-29T16:41:51Z

internal/compiler/object_tree.rs

+            {
+                r.property_declarations.insert(prop_name.clone(), prop_decl.clone());
+            }
+        }


This likely needs more checks, e.g. that the properties do not already existed on base components.

0x6e · 2025-11-29T16:42:25Z

internal/compiler/object_tree.rs

            });

+            if base_type == ElementType::Interface && visibility == PropertyVisibility::Private {
+                diag.push_warning(


Should be an error.

0x6e · 2025-11-29T16:44:44Z

internal/compiler/object_tree.rs

+                let message = format!(
+                    "Cannot override binding for property '{}' from interface '{}'",
+                    prop_name, uses_statement.interface_name
+                );


I struggled to come up with a test case for this error - the previous checks caught it first. Suggestions would be appreciated.

I think this would be something like

property <XXX> foo: something; foo: something_else;

Or, in your case:

... use ... (that has a property foo with a binding) foo: something_else;

Unclear if this should be an error actually.

0x6e · 2025-11-29T16:45:54Z

internal/compiler/parser/document.rs

        if p.peek().kind() == SyntaxKind::ColonEqual {
-            p.warning("':=' to declare a global is deprecated. Remove the ':='");
+            let description = if is_global { "a global" } else { "an interface" };
+            p.warning(format!("':=' to declare {description} is deprecated. Remove the ':='"));


Should be an error for interfaces?

i'd say so.

ogoffart

Looks very good, thank you.

I think that apart from the failling CI, this could actually be merged.
I just wrote some comments that could make the patch even better.

ogoffart · 2025-12-01T08:56:41Z

internal/compiler/object_tree.rs

+    interface_name_node: syntax_nodes::QualifiedName,
+    child_id: SmolStr,
+    child_id_node: syntax_nodes::DeclaredIdentifier,


Not a big issue, but maybe it's enough to have only one node like:

Suggested change

interface_name_node: syntax_nodes::QualifiedName,

child_id: SmolStr,

child_id_node: syntax_nodes::DeclaredIdentifier,

node: syntax_nodes::UsesIdentifier,

child_id: SmolStr,

As it is trivial to access the child node with node.QualifiedName() and node.DeclaredIdentifier()

ogoffart · 2025-12-01T09:00:05Z

internal/compiler/parser.rs

+        /// `uses { Foo from Bar, Baz from Qux }`
+        UsesSpecifier -> [  UsesIdenfifierList ],
+        UsesIdenfifierList -> [ *UsesIdentifier ],


Minor again, but I'm thinking we don't need the USeIdentifierList node and we can have

Suggested change

/// `uses { Foo from Bar, Baz from Qux }`

UsesSpecifier -> [ UsesIdenfifierList ],

UsesIdenfifierList -> [ *UsesIdentifier ],

/// `uses { Foo from Bar, Baz from Qux }`

UsesSpecifier -> [ UsesIdentifier ],

ogoffart · 2025-12-01T10:00:20Z

internal/compiler/parser/document.rs

        if p.peek().kind() == SyntaxKind::ColonEqual {
-            p.warning("':=' to declare a global is deprecated. Remove the ':='");
+            let description = if is_global { "a global" } else { "an interface" };
+            p.warning(format!("':=' to declare {description} is deprecated. Remove the ':='"));


i'd say so.

ogoffart · 2025-12-01T10:05:25Z

internal/compiler/object_tree.rs

+    fn try_from(
+        node: &syntax_nodes::UsesIdentifier,
+    ) -> Result<Self, <Self as TryFrom<&syntax_nodes::UsesIdentifier>>::Error> {
+        let interface_name_node = node.child_node(SyntaxKind::QualifiedName).ok_or(())?;


You should be able to do node.QualifiedName()

ogoffart · 2025-12-01T10:09:58Z

internal/compiler/object_tree.rs

+                            &base_node,
+                        );
+                        ElementType::Error
+                    } else if !diag.enable_experimental {


(maybe this should be the first condition?)

ogoffart · 2025-12-01T10:19:55Z

internal/compiler/object_tree.rs

+                let message = format!(
+                    "Cannot override binding for property '{}' from interface '{}'",
+                    prop_name, uses_statement.interface_name
+                );


I think this would be something like

property <XXX> foo: something; foo: something_else;

Or, in your case:

... use ... (that has a property foo with a binding) foo: something_else;

Unclear if this should be an error actually.

ogoffart · 2025-12-01T10:21:23Z

internal/compiler/object_tree.rs

+    }
+}
+
+/// Check that the given element implements the given interface. Emits a diagnostic if the interface is not implemented.


So this is like implicit interface where the components itself didn't explicitly sayd implements <...>
I'm wondering if interface implementation shouldn't be explicit.

Yes. My initial approach was to store the list of interfaces that were implemented as a member of the element (i.e. interfaces should be explicit). That wasn't working because the list was getting lost/not available where I was expecting it, so I switched to this approach for the proof-of-concept. I'd be happy to look at explicit interfaces as a follow-up.

ogoffart · 2025-12-01T10:24:46Z

internal/compiler/parser/document.rs

+/// component F uses { I from A } implements J { }
+/// component F uses { I from A } inherits B { }
+/// component F uses { I from A, J from B } { }
+/// component F uses { I from A, J from B } implements J { }
+/// component F uses { I from A, J from B } inherits C { }


I'm not sure we should support having both Implement ans inherits or having several interface.

I don't see why you wouldn't want to support implements and inherits for the same component. For example,

interface ButtonInterface { callback clicked; } export component MyButton implements ButtonInterface inherits Rectangle { }

means that the both the rectangle and interface APIs are available to the user of MyButton. Alternatively we have to verbosely duplicate all the API we want to expose from MyButton, which kind of defeats the purpose of the interface.

I also don't see why you wouldn't want to be able to expose more than one interface. In principle std-widgets might want to expose at least two: the particular std-widget interface, and an accessibility interface.

ogoffart · 2025-12-01T10:28:26Z

internal/compiler/parser/document.rs

+    let mut p = p.start_node(SyntaxKind::UsesIdentifier);
+
+    if !parse_qualified_name(&mut *p) {
+        return false;


I think we need to have the node aven in case of error, otherwise we unwrap in some places:

Suggested change

return false;

drop(p.start_node(SyntaxKind::DeclaredIdentifier));

return false;

Same thing for the next if

Ah, that was why I ended up with the TryFrom. Thank you.

ogoffart · 2025-12-01T10:29:14Z

internal/compiler/passes/resolve_native_classes.rs

                }
-                ElementType::Global | ElementType::Error => panic!("This should not happen"),
+                ElementType::Interface => {
+                    // TODO: I don't think we should be here - but it is too early to tell. Don't panic though.


This pass happens at the very end, so this is indeed unreachable.

0x6e added 19 commits November 28, 2025 17:46

compiler: Introduce ElementType::Interface

a652e16

Add a new ElementType variant that will allow us to parse interface declarations using the existing element parsing code. The match arms implemented are my best guess based on the context of the enclosing function and how a global is handled.

compiler: interface is a valid top-level item keyword

9140259

A document may contain zero or more interfaces. Interfaces do not support inheritance.

compiler: An interface excludes the same content as a global

344bb4d

Verify that an interface cannot have: - sub elements; - repeated elements; - property animations; - states; - transitions; - an init callback declaration; - an init callback implementation.

compiler: An interface can have public properties

d6a7f12

Warn if private properties are declared.

compiler: implements is a valid keyword

610f62d

It is treated as an alias for `inherits`, for now.

Move existing interface syntax texts to syntax/interfaces

f4a8fdd

Group interface related tests in a subdirectory of their own.

compiler: Add uses specified as valid new component syntax

5a258f5

Allow a new component to specify that it exposes one or more interfaces via a given child element. This commit introduces the syntax, we will add the implementation in a future commit.

compiler: emit errors for invalid interfaces in uses statements

7d15b3e

Detect and emit errors where: - the type specified in a uses statement is not an interface; - the type specified in a uses statement is unknown; - the type specified in a uses statement cannot be used in this context.

compiler: emit an error when the child specified in a uses statement …

a3a01a7

…does not exist Add a test case to verify the expected error message.

compiler: verify that external interfaces can be implemented

461058d

Add a test to verify that interfaces from imported modules can be used.

compiler: verify that renamed components and interfaces can be used

e7839af

Add a test case to verify that: - we can import an interface as another name and re-use it; - we can import a component that implements a renamed interface and use it.

compiler: do not allow interface properties to be overridden

c4d0e94

Emit a compile error if the user attempts to declare a property that would override a property from an interface.

compiler: do not permit interfaces to be used if they would override …

ab7e54c

…an inherited property Look up the interface property on the base type before allowing a component to implement the interface.

compiler: emit an error if a uses statement attempts to override an e…

505b81b

…xisting binding I couldn't figure out a good way to test this - everything I came up with got caught by the prior check that the property does not already exist.

compiler: 'interface', 'implements' and 'uses' are experimental features

a184d42

Guard these keywords behind the experimental features flag. Slint must be compiled with the `SLINT_ENABLE_EXPERIMENTAL_FEATURES` environment variable set to enable these keywords.

0x6e commented Nov 29, 2025

View reviewed changes

ogoffart reviewed Dec 1, 2025

View reviewed changes

	return false;
	drop(p.start_node(SyntaxKind::DeclaredIdentifier));
	return false;

Add interfaces as a proof-of-concept experimental feature #10181

Are you sure you want to change the base?

Add interfaces as a proof-of-concept experimental feature #10181

Uh oh!

Conversation

0x6e commented Nov 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ogoffart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants