Done

Done

Hm it is all semantics, so a tough problem to solve :p I don't have a strong preference

I suggest renaming struct MyContract to struct MyStorage, the examples above are quite confusing. This could also help with this:

Embed for me sounds like you're embedding one contract in another, including its behaviours...?

why is #[extends] or similar needed if there's no flattening?

I suggest renaming struct MyContract to struct MyStorage, the examples above are quite confusing. This could also help with this:

Embed for me sounds like you're embedding one contract in another, including its behaviours...?

Done

why is #[extends] or similar needed if there's no flattening?

Regular members are different than the compose(renamed from extends) ones.
A member is turned into a storage variable accessor. self.member won't be of the typoe specified, it will be something like StorageVar.
A composed contract on the other hand will have the type as is, or perhaps something like Substorage<Type> to allow passing it as the self to other functions.

2. Requirement of the "annotated module" syntax. These functions need access to storage variables which is only possible there in the module, but they shouldn't be part of the abi.

1. Actually, I even used the word "face" in a previous version to describe just that. These impls are exactly faces. Sound like you have some concrete syntax suggestion, but I'm not sure what it is. Can you describe it? Also include what is the "deployed contract" and its abi please:)

3. Added some proposal for constructors:)

Views: I thought of something like this:

#[starknet::storage]
struct MyContract { ... }
#[starknet::view(MyContract)]
struct USDCMyContract {
 contract: MyContract,
}
impl ERC20 for USDCMyContract {
 ...
}
#[starknet::view(MyContract)]
struct PLNMyContract {
 contract: MyContract,
}
impl ERC20 for PLNMyContract {
 ...
}

Note: Implementing trait directly on contract struct will mean creating a Default view.

The deployed contract's ABI will include identifiers of all possible views, and I imagine having a function MyContract::view::<PLNMyContract>()

That sounds like the rust way of overcoming the inability to have multiple impls. Wrapper types are good in that case.

But in Cairo, you have multiple impls, and impls will be first class citizen. So no need to have wrapper types.

Interesting.
I like it, but I'm missing some details about how that migth work under the hood.
The storage struct that the user provides, at least in how I thought about this proposal is not "real" - it would get translated to something else.
Example:

#[starknet::storage]
struct MyContract {
 balances: Mapping<address, u128>,
 owner: address,
 #[compose]
 other: OtherContract
}

This actually might get translated (in the current suggestion) to something like

struct MyContract<const selector> {
}
impl MyContract<const selector> {
 balances: Mapping<mix(selector, 'balances'), address, u128>,
 owner: StorageVar<mix(selector, 'owner', address>
 other: OtherContract<mix(selector, 'other')>
}

So, what does construct actually return?
Maybe we need another generated struct for initialization?
And it will still need to support the set interfance, and maybe even call functions that are supposed to get MyContract.

Hmm, with associated types (present in Rust, not in Cairo), you could actually attach a separate struct to use by the constructor:

struct MyContract<const selector> { ... }
struct MyContractPure {
 balances: Mapping<address, u128>,
 owner: address,
 // composed fields are not obvious to me, whether include them here or not?
}
impl MyContract<...> {
 type Initializer = MyContractInitializer;
}

This struct could be only used in constructor, but I would also happily see a function that builds *Pure on demand in contract code. Could be useful?

Ad 1. Does it mean that in order to refer to some contract ABI I will need to provide type of its storage(ERC20<Storage> vs just ERC20)?
Ad 2. Why would I want to use ABIs internal functions? They should not be accessible to the external users, unless contract encapsulation model is very different from what we know from ethereum.

is there any interest/possibility of having function overloading in cairo1? if the dispatcher is already distinguishing between ERC721::transfer_from and ERC20::transfer_from, could it also distinguish between ERC721::safe_transfer_from(from, to, token_id) and ERC721::safe_transfer_from(from, to, token_id, data)?

Why would I want to use ABIs internal functions? They should not be accessible to the external users, unless contract encapsulation model is very different from what we know from ethereum.

i think there's extensibility use cases where you'd need access to internal functions (e.g. _approve in ERC20) but that's not part of the ABI. should all extensibility be ABI-based?

Perhaps we can have trait-based extensibility and use function decorators to specify if the function should be present in the ABI.

Something like

#[starknet::abi(event=ERC721Event)]
trait IERC721<T> {
 #[view]
 fn balance_of(self: T, user: address) -> u128;
 #[internal] // or no decorator at all
 fn _mint(self:T, to: address, token_id: u128);
}
#[starknet::abi(event=ERC721MintableEvent)]
trait IERC721Mintable<T> {
 #[external]
 fn mint(self:T, to: address, token_id: u128);
}
#[derive(Event)]
enum ERC721Event {
 TransferEvent,
}
#[derive(Event)]
enum ERC721MintableEvent{
 MintEvent,
}
impl ERC721BaseImpl<MyContract> of IERC721::<MyContract> {
 fn balance_of(self: MyContract, user: address) -> u128 {
 self.balances.get(user)
 }
 fn _mint(self: MyContract, to: address, token_id: u128) {
 self.balances.set(to, token_id);
 }
}
impl ERC721Mintable<MyContract> of IERC721Mintable::<MyContract>{
 fn mint(self:MyContract, to: address, token_id: u128){
 self._mint(123, 1_u128);
 }
}

and then the contract ABI is the union of all ABIs of traits implemented

You don't need the internal function uin the abi: it's not a part of the interface, and use can just have a free function (not inside the trait), ior just have a non-abi trait for your type. the abi trait is just for the interface. I don't see a benefit to putting it in the trait.

That is not in line with the rest of the language.
Why would it be possible in event but not in enum?

In Rust it is possible to have an enum variant with named fields. Listing 6-2 in: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html

Right. Not so in Cairo1. So maybe your suggestion is towards the enum syntax rather than contract syntax?

I answered at #2058 (comment)

Funny how a comment with loosely defined terms became the most upvoted one in the discussion 😅

By extend and leverage I mean to reuse/inherit the functionality of a module or contract in another contract. This was discussed in the forum and the extensibility pattern became the predominant one in the language. Even the #[extends] macro was proposed above.

For example, the ERC165 module provides introspection functionality for contracts to reply through a supportsInterface getter whether they support a given interface or not. Accounts leverage this module (methods and associated storage) for many reasons, e.g. to let ERC721 contracts know they can handle tokens.

The problem though (and hence my questions above) is how to deal with a chain of dependencies since the proposed solutions above assumed the Account contract should be aware of the ERC165 storage structure which does not scale when there's multiple modules/contracts involved.

Given there's zero documentation on Cairo 1, this was completely unknown to me when I asked this a month ago; but now having played more with the language I get a better idea of what you mean by "call code of an implementation of another contract", although I'm not sure what you mean by "pass the required storage" since this is not needed today and IMO the best for encapsulation.

Wasn't attacking. I literally was rereading a dozen times before giving up. That's also why I didn't originally reply.
We are in a "documentation" week, so more and more docs should become available the next few days:)

Note that Cairo is not going the object oriented way, and inheritance is not supported.
Instead, it encourages composition and polymorphism through traits and impls.

I think I gave the usage example above for everything this suggestion includes. If you jave a concrete question about how to implement something, I'd be happy to provide a sample implementation.

An example of how would a contract A extend/compose a contract B that in turn uses another C contract would be very useful, if there's one above please link it since i've missed it. This is how we're extending modules today -- although you warned us that would stop working eventually (not sure why). I would assume that calling modules directly would be enough since it encapsulates storage while exposing reusable methods, but then I was puzzled when you said "you can just call it as code, and pass the required storage". Maybe I'm not understanding what you meant, but even if there's composition instead of inheritance wouldn't that require a contract to be aware of the storage used by a subcontract?

Another question would be how impls are expected to work. Today you cannot use the #[contract] directive on an impl, nor impls can have storage. How do you envision an IERC165 trait being implemented by an ERC165 impl (which has its own storage), that is used by an Account impl, which should also be composable/used by another impl/contract? Or how would you model such modules?

An alternative would be to implement everything as contracts as we're doing today, but then they can't impl X of to make sure you're following an interface (trait).

Since contracts can't use traits and traits can't use storage, today we're embedding impls into contracts which is very ugly.

Here is one possibility:

// b.cairo
#[storage]
struct B {
 #[compose]
 b: C
}
#[abi]
trait BTrait<Storage> {
 fn bar(self: B);
}
impl BImpl of BTrait<B> {..}
// a.cairo
#[storage]
struct A {
 #[compose]
 b: B
}
#[abi]
trait ATrait<Storage> {
 fn foo(self: A);
}
impl AImpl of ATrait<A> {
 fn foo(self: A) {
 self.b.bar(); //self.b is of type B, which is B's storage. We are passing it to bar.
 }
}

This is the composition pattern.
Another useful pattern (the equivalent for the diamond pattern in inheritence), when C is actually some interface that is needed by B0 and B1, both used by A. Here, B0 doesn't want to own C, just make sure it exists on the implementor - so it is not a standalone contract, but a component.

// starknet.cairo
trait HasStorage<Storage, SubStorage> {
 fn get(self:Storage) -> SubStorage;
}
// b0.cairo
#[storage]
struct B0 {..}
#[abi]
trait B0Trait<Storage>;
// Generic implementation for anything that has B0 and C.
impl B0Impl<Storage, impl HasB0: HasStorage<Storage,B0>, impl HasC: HasStorage<Storage, C>> of B0Trait<Storage>{
 fn foo(self: Storage) {
 HasB0::get(self).foo()
 HasC0::get(self).foo()
 }
}
#[storage]
struct A {
 #[compose] // will auto-implement HasStorage<A, C>
 c: C,
 #[compose]
 b0: B0,
 #[compose]
 b1: B1,
}
impl AImpl of CTrait<A> { ... }
// impl alias
impl AB0Impl = B0Impl<A, _, _>;

The intent here is not to guarantee behavior. It is to guarantee that the developer did not do a mistake with adhereing to the interface. The actualy implementation can be whatever he wants

Yes, I agree with this:)
We still need to work out the details of the syntax.
I think I like the contract_class name vs the old contact

Is this related to the suggestion above? Or to the current Cairo 1 syntax?
Anyway, event.emit() makes sense to me.

Is this related to the suggestion above? Or to the current Cairo 1 syntax?

For the current Cairo 1 syntax, wasn't sure where was the best place to start a discussion on this.