Feature Request: Consistent use of default = FluidDefaultAllocator() on algorithm constructors

[AlexHarker]

Is your feature request related to a problem? Please describe the problem.

Code is inconsistent in the use of = FluidDefaultAllocator() as a default argument on algorithm constructors

Describe the solution you'd like to see.

For the usage to be consistent. The advantage of no default argument is that it reduces the risk of accidental usage of the default allocator. The disadvantage is that it requires a specific choice for all uses of the algorithms.

If @weefuzzy can provide a preference the consistency could easily be ensured by others.

Describe alternatives you've considered

None (expcept that it stays as it is)

Additional context

That's quite enough context.

[weefuzzy]

Hmm, yeah. My basic position is that I dislike default arguments generally, and those were there primarily to minimize the leakiness of the commits as I added allocator stuff. When I remembered, obviously.

In favour of taking them out: clients (audio ones at least) should always be passing an allocator in – and one fine day someone might get round to making a better arrangement for Max / PD as well as SC. Downer, of course, is that this needs documenting.

The argument for keeping them in is an appeal to using the algorithms as a standalone API, and not having to worry about such things. I don't know that anyone's doing this yet, and I'm not convinced that a really clean simple algorithms API is simple to achieve alongside all the actual needs of the client code, without some additional wrapping at least.

So, I'm leaning towards purging them.

[AlexHarker]

Cool - I will make this a task for those who have time for such tasks