There is also quite a lot of todos in the code.

There is also quite a lot of todos in the code.

To be fair, it's marked inprogress :)

small update, also I'll wait for #1809 and then impl for linked_map.

• user of Balance don't have anything to change now as a new keyword has been added to the decl_storage macro to be able to specify to skip phantom data field when we know it is not necessary.

small update:

• implemented for linked_map,
• still have to do documentatio and test and construct_runtime

but otherwise eveything seems fine to me.

working the construct_runtime it will probably end up to something like
Example0: example::{Module<example::Instance0>, Event<T, example::Instance0>}

also as a note: I wonder in how many situation this would be useful. If we want to implement it for balance at the end then it worth implementing this way. But if we only expect some user to implement it for a few cases then I don't know if it worth maintaining this way. Because one could simply do a macro that append the storage name and create multiple instance:

multiple_module! {
  pub trait Trait: system::Trait {
  }
  decl_module! {
  ...
}

with multiple_module macro expanding to

mod module1 {
  pub trait Trait: system::Trait {
  }
  decl_module! {
  ...
  storage as Module1
  ...
}

mod module2 {
  pub trait Trait: system::Trait {
  }
  decl_module! {
  ...
  storage as Module2
  ...
}

And this would be equivalent in terms of feature for other modules and runtime.

EDIT: or might be better in build.rs

@gavofyork actually I wonder about your opinions on this feature, mine are mixed.
The good part is that it is entirely backward compatible it only extend definiton of modules. the bad part is that it add a bit of complexity on our side for a need I don't know how to estimate.
But if the need is here. It seems doable

Some feedback from a parachain developer.
We are working on a chain with multiple tokens and we have a module implements all the tokens. It provides multiple implementation of the Currency trait so we can pass different Currency trait to different modules.
We don't need multiple instantiations of a module, we need multiple implementations of a trait, which is already supported.
The general trend of runtime modules should be depending on traits, instead of depending on a particular module.

thanks @xlc
as a note I could imagine a use case like a module requiring two currency:

trait Trait {
  type Currency1: Currency;
  type Currency2: Currency;
}

a user of this module could use balance for each currency but with two different instance

impl Trait for Runtime {
  type Currency1 = balance::Module<Self, balance::Instance1>;
  type Currency2 = balance::Module<Self, balance::Instance2>;
}

small update: I am more confident in the code now, still have to check Log part and inherent part.
Also the new syntax is implemented you can take a look at node/runtime as I temporarly pushed the test:

construct_runtime!(
	pub enum Runtime with Log(InternalLog: DigestItem<Hash, SessionKey>) where
		Block = Block,
		NodeBlock = node_primitives::Block,
		UncheckedExtrinsic = UncheckedExtrinsic
	{
		System: system::{default, Log(ChangesTrieRoot)},
....
		Balances1: balances::<Instance1>::{Event<T, I>},
		Example: example::<Instance1>::{Module, Call, Storage, Event<T, I>, Config<T, I>, Origin<T, I>},
	}
);

full example builds, inherent, origin and log are implemented.

it requires parity-codec to implement Codec for core::marker::Phantom

@thiolliere is the minor release something you can take care of?

i'l like to push forward and get this in now.

Wouldn't it be easier and much less inversive to add the instance as associated type?

@bkchr we can't implement multiple times the same trait with a different associated type, either we make the trait generic or we provide multiple traits.

note: indeed providing multiple traits could be a solution, I would implement it with a global procedural macro like

// expand to multiple modules or a single module but different trait like TraitInstance2, TraitInstance3
// rename storage name for each implementation as $(ModuleName)Instance2, ModuleNameInstance3
decl_multiple_instance! {
// whole module except imports
}

ok codec published, dependency updated, and master merged