Meta-issue: Features

[rossberg]

Small:

• Support checking mode for records (Support analysis mode typing for record literals? #2240)
• Remove deprecated object/block syntax (Record syntax too confusing and inconsistent #1294)
• Make actor{} a subtype of Principal (actor t <: principal #2264)
• Require type annotations on public class fields (Type inference bug? #1290)
• Only allow 'query' short-hand in actor fields, 'shared query' elsewhere (Only allow 'query' short-hand in actor fields, 'shared query' elsewhere #741)

Medium:

• Remove Word types (Deprecating and removing Word types (stage I) #1824, Word deprecation: Phase 2 #2362, Word removal: Phase 3 #2363)
• Directed typing of operators (Operators: Synthesis left, analysis right? #853)
• Better error messages for complex type mismatches (Diff or trace for type mismatches #2313)
• Import patterns and type patterns (Allow explicit imports #2354)
• do monad construct
• Identifier escaping (Add identifier escaping #1668)
• Operator sections? (Passing operators as function arguments? #816)
• Type fields in types and records (Support type components in object type syntax #760)
• Consolidate oneway methods (Safeguard against accidental oneway calls? #950)
• Sharable modules (Modules are currently not sharable, but could be #1452)
• User-defined deprecations (User-defined deprecations #2361)
• Record merging and field extension (Provide syntax for functional record update operations #3072)

Large:

• Cycles and funds (Implement Funds support in interpreters #1981, blocked)
• Shared generics (Shared generics #2096, Debug.show instead of debug_show #1655, Generalize debug_show/serialization to support deriving traits for mono types #1500)
• Expose serialisation primitives (Expose IDL serialisation as primitives #1183)
• Intersection and union types, mixins (Add syntax for type intersection and union #1841)
• Warn against atomicity bugs? (Warning against reentrancy / non-atomicity #792)
• Atomic sections? (Consider adding an *atomic* expression (syntax atomic <exp>) #1361)
• Effect system? (Effect system for IO? #703)
• Define public fields through type annotations? (Better readability for identifying public fields? #2164)
• Canister parameters (Candid/Motoko) (Canister argument IDL story #1827, Support actor init args in mo_idl/idl_to_mo.ml #2120)
• Stable functions and objects (A sketch for stable functions #707)
• User-defined custom serialisation?

[nomeata]

Trac really shined at making such ad-hoc lists of issues useful (by turning them into tables with metadata like status – github doesn’t even mark links to closed issues differently :-()

[chenyan-dfinity]

Another issue worth considering: Upgrade class object in stable memory (https://github.com/dfinity/dx-triage/issues/40)

[crusso]

The restrictions of #703 (Effect System) are already enforced, just not with a standard effect system.

[crusso]

I believe "Canister parameters" is long done, both in Motoko and IDL - not sure about dfx? @chenyan-dfinity?

[chenyan-dfinity]

dfx is also done.

$ dfx canister install --help
OPTIONS:
        --argument <argument>                        Specifies the argument to pass to the method
        --argument-type <argument-type>
            Specifies the data type for the argument when making the call using an argument
            [possible values: idl, raw]

[chenyan-dfinity]

I think the open issue here is for Motoko to import .did file that contains actor class and instantiate it.

[rossberg]

Another issue worth considering: Upgrade class object in stable memory (dfinity/dx-triage#40)

Stable objects would require stable functions, so I extended that item. An alternative would be to support conversion hooks for serialisation, i.e., user-defined serialisation formats. Also added an item for that, though it's unclear how to do that.

I believe "Canister parameters" is long done

My understanding is that there still are various loose ends about did files containing such parameters, e.g., how to remove them when uploading the canister, or how to import them?

[crusso]

I think the open issue here is for Motoko to import .did file that contains actor class and instantiate it.

I think that is equivalent to adding support for foreign actor classes, which was tracked here:

#1905

With our current compilation scheme (quoting the wasm in wasm), this would require both the .did file and the actual wasm of the imported class, or some way to install/retrieve an actor class install on the system.

I don't think Andreas was a fan of foreign actor class import, should we rethink?