Re: [PATCH] `affixation-function`: Allow only three-element lists

[Daniel Mendler <mail@daniel-mendler.de>]

On 4/25/21 10:34 PM, Juri Linkov wrote:
> I completely agree that for `affixation-function` part of
> the API is would be cleaner to document the input data as
> only candidate + prefix + suffix.
> 
> But I don't agree with `cl-assert`.  It looks too odd.
> Why to validate that the length of the first candidate is 3?
> Why not to validate than the length of every candidate
> is not more than 3?  Why not to validate that there are no nils
> in the list?  Why not to validate there are only strings?  Etc.
Okay, fair enough. I am fine if the `cl-assert` is removed from the 
patch. The other changes should be kept though, such that we do not 
violate the more restricted specification. Other completion UIs may not 
support the two-element affixations which are then still accidentally 
allowed by the default completion UI. The `cl-assert` is just a cheap 
check to ensure that no violating affixation functions are accidentally 
reintroduced. But you are right that this is not fail-safe. Do you want 
me to send an updated patch with the `cl-assert` removed?

Daniel