Michael Müller

To persist what we decided on: * It's confusing to users that we use different terms synonymously. * We no longer want to use the terms deploy/initialize for instantiating a...

Some lints can also be configured in a `clippy.toml`: https://github.com/rust-lang/rust-clippy#configuration. Not sure if this is applicable here.

@xgreenx You can get the `ink-waterfall` stage to run by removing the failing CI checks altogether from `.gitlab-ci.yml`. So just remove all failing stages (`clippy-std`, `clippy-wasm`, etc.) and push these...

@willser For sure you could pick it! I think the change needed in ink! is to make `#[ink(constructor)]`'s and `#[ink(message)]` optional, but require that at least one of them is...

As part of this ticket you should also add new tests in `ink/crates/lang/tests/ui/contract/`. You can also remove the constructors in [`examples/upgradeable-contracts/delegate-calls/upgradeable-flipper/lib.rs`](https://github.com/paritytech/ink/blob/master/examples/upgradeable-contracts/delegate-calls/upgradeable-flipper/lib.rs#L29-L41) then.

@willser I need to revert my go from earlier today, there's some more stuff to consider here. I'll try to post some more on it tomorrow, but please hold off...

@willser Sorry for the delay, you're good to go. There was some discussion on if we actually want to make ink! messages and constructors optional and the decision is yes.

>I am not sure if this is entirely bad since this is an artifact of the actual Rust code itself. Yeah sure, but I think we shouldn't require people to...

@xgreenx We think the best way forward would be to iterate on your example and get rid of the unsafe transmute. For the host functions you could mock them for...

@xgreenx Regarding `#[ink(storage)]` and `#[ink::storage_ext]`: In an ideal world we would need only `#[ink(storage)]` and detect if the `struct` is meant to be the top-level storage item or a nested...