Fuzion • Fuzion Design • Feature Kinds

Feature Kinds

A major design goal of Fuzion is to unify different concepts into the single concept of a Fuzion feature. This makes a Fuzion feature a very powerful mechanism. Nevertheless, Fuzion features are not all the same, there are different kinds of features and what can be done with one feature might not be possible with a different kind of feature. The following table gives an overview of what can be done with features of different kinds.

But first, let's see what all features have in common

What all features have in common

Feature name

All features declared in Fuzion have a feature name. The name is typically just an identifier such as execute, or an operand such as postfix !.

Feature nesting

All features are declared within the context of an outer feature. This outer feature is the feature that syntactically surrounds the feature declaration. In case there is no explicit feature surrounding a feature declaration, the outer feature is an implicit feature called universe.

Differences between Feature Kinds

Fuzion Features are of one of several kinds and not all features can be used in every context. This gives an overview of the feature kinds and what they can do.

Feature Kind Property	Constructor	Routine	Field	Intrinsic	Abstract	Choice	Function
Defines Type	✅ Yes	✅ Yes¹	❌ No	❌ No	❌ No	✅ Yes	✅ Yes
May contain code	✅ Yes	✅ Yes	❌ No	❌ No	❌ No	❌ No	✅ Yes
May contain declarations	✅ Yes	✅ Yes	❌ No	❌ No	❌ No	✅ Yes²	✅ Yes
May be redefined	❌ No³	✅ Yes	✅ Yes	✅ Yes	✅ Yes	❌ No	❌ No³
May redefine	❌ No	✅ Yes	✅ Yes	✅ Yes	✅ Yes	❌ No	✅ Yes⁴
May have formal arguments	✅ Yes	✅ Yes	❌ No	✅ Yes	✅ Yes	❌ No	✅ Yes
Has explicit result type	❌ No	✅ Yes⁵	✅ Yes⁵	✅ Yes	✅ Yes	❌ No	❌ No
May have formal type arguments	✅ Yes	✅ Yes	❌ No	✅ Yes	✅ Yes	✅ Yes	✅ Yes
May be called	✅ Yes	✅ Yes	✅ Yes	✅ Yes	❌ No	❌ No	✅ Yes⁶
May be assigned to	❌ No	❌ No	✅ Yes	❌ No	❌ No	❌ No	❌ No
May be called in inheritance clause	✅ Yes	❌ No	❌ No	❌ No	❌ No	❌ No	✅ Yes
May inherit	✅ Yes	✅ Yes	❌ No	❌ No	❌ No	❌ No	✅ Yes
¹The inner type of a routine is anonymous, so it cannot be used in declarations. ²Inner features may be constructors or routines, not fields. ³Redefinition would require dynamic binding in inherits call which results in trouble since different targets in that call would result in different inherited features. ⁴Requires type defined by constructor to be compatible to result type of redefined feature. ⁵Result type may be inferred from returned or assigned expression. ⁶There are two ways to call a function: Calling its constructor and calling its inner feature `call`.

Examples

Defining a Type

Constructor

One restriction is that type names must not be ambiguous. Overloading of constructors results in the corresponding types to be no longer usable since Fuzion does not permit a means to disambiguate overloaded types:

Routine

A routine does define a type, but this type is anonymous. It does not have a name that we could use in a declaration. However, type inference can be used to create features using a routine's type:

An instance of a routine's implicit type can even exist longer than the routine's call itself. Here is an example that shows a routine in a closure that extends the life span of the routine's instance until after the call to the routine has returned:

Negative example: Using a routine's name explicitly as a type does not work since a routine does not define a name for its type:

Field

Intrinsic

Abstract

Choice

Containing code

Constructor

Routine

Field

Intrinsic

Abstract

Choice

Containing declarations

Constructor

Routine

Field

Intrinsic

Abstract

Choice

Positive example declarations:

# example using a choice feature that contains declarations
dec_choic is

  # Declaring a choice feature foo
  foo : choice unit i64 true_ is

    # declaring an inner constructor
    constr is
      say "foo.constr"

    # declaring an inner routine
    routi String =>
      "foo.routi"

    # declaring an inner intrinsic feature
    intri unit => intrinsic

    # declaring an inner abstract feature
    abstr unit => abstract

    # declaring an inner choice type
    choic : choice i32 nil bool is

  f foo := unit
  _ := f.constr
  say f.routi

  say "calling f.abstr will cause error."
  _ := f.abstr                  # error!

  say "calling f.intri will cause error."
  _ := f.intri                  # error!

What are effects?

Negative example declaring a field:

Being redefined

Constructor

Routine

Field

Intrinsic

Abstract

# example using an abstract feature that is redefined
brd_abstr is

  parent is
    # Declaring an abstract feature foo
    foo unit => abstract

  rparent ref : parent is

  heir : rparent is
    redef foo unit =>
      say "heir.foo"

  # test calling foo dynamically
  test (r rparent) unit =>

    # using normal call
    r.foo

    # using inheritance call
    q unit : r.foo => {}         # NYI: currently causes 'Could not find called feature 'foo', need to check why
    q

  test heir
                                  # NYI: this error is only emitted in middleend. since frontend already errors,
                                  # this error is currently not shown.
  test rparent                    # error! will result in calling abstract feature

What are effects?

Choice

Redefining

Constructor

Negative example with compatible types that could be permitted, but is forbidden:

# example using a constructor feature to redefine another feature
red_const is

  parent is
    # foo has result type equal to result of heir.foo2
    foo red_const.heir.foo => abstract

    # foo2 has result type compatible to result of heir.foo2
    foo2 String => abstract

  rparent ref : parent is

  fixed heir : rparent is  # must be fixed to fix outer type to red_const
    # redefine foo using a constructor with equal result type
    redef foo is                  # error! Even though this could work in this
                                  # special case, a redefinition cannot be a constructor
      say "heir.foo"

    # redefine foo2 using a constructor with compatible result type
    redef foo2 ref : String is    # error! Even though this could work in this
                                  # special case, a redefinition cannot be a constructor
      redef utf8 => "heir.foo2".utf8

  p red_const.rparent := heir
  _ := heir.foo
  say heir.foo2

What are effects?

Negative example with incompatible types:

Routine

Field

Intrinsic

# example using an intrinsic feature to redefines another feature
red_intri is

  parent is
    foo unit => abstract

    foo2 String => abstract

    foo3 Any => abstract

  rparent ref : parent is

  heir : rparent is
    # redefine foo as an intrinsic with same unit result type
    redef foo unit => intrinsic         # error! compiler does not know this intrinsic

    # redefine foo2 as an intrinsic with same result type
    redef foo2 String => intrinsic      # error! compiler does not know this intrinsic

    # redefine foo3 as an intrinsic with compatible result type
    redef foo3 String => intrinsic  # error! compiler does not know this intrinsic

  p rparent := heir
  say p.foo
  say p.foo2
  say p.foo3

What are effects?

Abstract

Choice

Having formal arguments

Constructor

Routine

Field

Intrinsic

Abstract

Choice

Having explicit result type

Constructor

Routine

Field

Intrinsic

Abstract

Choice

Having formal type arguments

Constructor

Routine

Field

Intrinsic

Abstract

Choice

Being called

Constructor

Routine

Field

Intrinsic

Abstract

Choice

Being assigned to

Constructor

Routine

Field

Intrinsic

Abstract

Choice

Being target of inheritance call

Constructor

Routine

Field

Intrinsic

Abstract

Choice

May inherit

Constructor

Routine

Field

Intrinsic

Abstract

Choice

last changed: 2024-06-28

next: Visibility