For your paper, your flagship problem with lasers is not caused by
design error rather than lack of support in langage?
For a long time many people have said that diamond hierarchies are
bad, I would not use such strong words but I think they should still
be avoided.

For your example better design would be invert hierarchy and have:

```
template<typename... Modifiers>
class Laser
{
    std::tuple<Modifiers...> _mod; //could be base classes
    void trigger()
    {
        (get<Modifiers>(_mod).apply(), ...);
    }
};
```

Your paper should consider and compare this with your solution.

niedz., 10 kwi 2022 o 18:29 Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> napisał(a):
>
> On Wed, Apr 6, 2022 at 9:41 PM Frederick Virchanza Gotham wrote:
>
> > For the timebeing I'm just bouncing ideas around.
>
> I have put together a 9-page PDF document in which I give the first
> thorough draft of my proposal. Specifically I address:
>
> * In cases of virtual inheritance, don't invoke the method in the base
> class more than once
> * Mark the method in the derived class as 'continue'
> * Mark the method in the base class as 'requires continue'
> * Mark the method in the derived class as 'break'
> * Specifying the order of invocation of methods with 'goto continue'
> * Use function call syntax with 'goto continue' to give customised arguments
> * The interaction of virtual and non-virtual functions in a chain of continuity
> * Excluding specific base classes by name if you don't want their
> method to be invoked
> * One thorough, extreme example showing all the proposed features
> working together
>
> You can download the document from my webspace here:
>
> http://www.virjacode.com/download/continuity_methods/continuity_methods_draft001.pdf
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals