🏗️ [Core Feature]: use `nightly` feature for mutual exclusivity

[ozgunozerk]

What is the key feature we're aiming to implement?

Right now, we are utilizing associated types and unit structs to enable mutual exclusivity.

Although this approach works, here is the problem with it:

• say, extensions A and B are incompatible
• say, C and D are incompatible

With our current approach, the following is impossible

• a contract with A and C
• this is due to, to enforce mutual exclusivity, we generate concrete types, say A, B, C, and D
• that's why, if it is A, it cannot be B. But similarly, if it is A, it cannot be C and D either...

We have an alternative solution to this, by utilizing combinatorics, we can have the following:

• AandC
• AandD
• BandC
• BandD

all these will be implementation details, that the end developer won't see and use at all. All the complexity will be hidden, hence, not a bad solution.

However, we found out a nightly feature, that enables us to enforce negative trait bounds directly, without any workarounds with positive bounds.

This feature alone, may be an enough reason to switch to nightly channel

[ozgunozerk]

Here is the proposed alternative solution if we are to continue with stable rust:

// ============ Marker Traits ============
// These indicate what capabilities a ContractType supports
pub trait SupportsVault {}
pub trait SupportsEnumerable {}
pub trait SupportsConsecutive {}


// ============ Unit Structs (Contract Types) ============
pub struct Base;
pub struct Enumerable;
pub struct Consecutive;
pub struct Vault;
pub struct VaultEnumerable;   // Composite: Vault + Enumerable
pub struct VaultConsecutive;  // Composite: Vault + Consecutive


// ============ Marker Trait Implementations ============
// Single extensions
impl SupportsVault for Vault {}
impl SupportsEnumerable for Enumerable {}
impl SupportsConsecutive for Consecutive {}

// Composites support BOTH
impl SupportsVault for VaultEnumerable {}
impl SupportsEnumerable for VaultEnumerable {}

impl SupportsVault for VaultConsecutive {}
impl SupportsConsecutive for VaultConsecutive {}


// ============ ContractOverrides Implementations ============
impl ContractOverrides for VaultEnumerable {
    fn transfer(e: &Env, from: &Address, to: &Address, token_id: u32) {
        // Combine both behaviors:
        // 1. Enumerable's transfer logic (owner enumeration updates)
        // 2. Vault's transfer logic (whatever vault needs)
        Enumerable::transfer(e, from, to, token_id);
        Vault::on_transfer(e, from, to, token_id); // Vault hook
    }
}

impl ContractOverrides for VaultConsecutive {
    fn transfer(e: &Env, from: &Address, to: &Address, token_id: u32) {
        Consecutive::transfer(e, from, to, token_id);
        Vault::on_transfer(e, from, to, token_id);
    }
}


// ============ Extension Traits with Marker Bounds ============
// Instead of: NonFungibleEnumerable: NonFungibleToken<ContractType = Enumerable>
// Use:
pub trait NonFungibleEnumerable: NonFungibleToken 
where 
    Self::ContractType: SupportsEnumerable 
{}

pub trait NonFungibleVault: NonFungibleToken 
where 
    Self::ContractType: SupportsVault 
{}

// Consecutive remains incompatible with Enumerable (no composite exists)
pub trait NonFungibleConsecutive: NonFungibleToken 
where 
    Self::ContractType: SupportsConsecutive 
{}



// ============ Usage (What the End Develope Sees) ============

impl NonFungibleToken for MyContract {
    type ContractType = VaultEnumerable; // Combines both!
}

impl NonFungibleEnumerable for MyContract { /* works! */ }
impl NonFungibleVault for MyContract { /* works! */ }

// This still won't compile - no type supports both Enumerable + Consecutive
impl NonFungibleConsecutive for MyContract { /* ERROR */ }