Add support for automatic type inference (enabled by default).

[Ambrevar]

I think it's a very useful default. But could it break existing libraries using compilers that do slot type checking?
(CCL is one of the few that does.)

[attila-lendvai]

i think this is too much DWIM-ness that easily leads to confusion.

just because i initialize a slot to some value, it doesn't mean that i want to restrict the type of all future values to that of the initform.

[Ambrevar]

Sure, but then you can always specify :type t to mean that this slot can be of any type.
Or we can disable type inference by default.

[Ambrevar]

Would you be OK with merging this if we disable type inference by default?

[Ambrevar]

@attila-lendvai Friendly ping! :)

[attila-lendvai]

your effort is appreciated, but i don't think this feature belongs into a general-use library.

my reasoning:

• it badly hurts code readability for not much in return. some lisps ignore the slot's :type declarations while others are rather strict about it. developing on one lisp may completely hide errors/warning that only show up as errors when tested on another lisp.
• it also increases code complexity and i suspect most people will not use this feature, or straight out don't even know that it exists if it's not on by default. complexity has a cost that is most often ignored.
• whoever decides to specify the slot's type is better off doing it explicitly

is this convincing enough?

[Ambrevar]

Well, allow me to counter-argue! :)

- it badly hurts code readability for not much in return.

True, the code could be better separated into smaller functions. This is also true to the original code, so we could improve this in all cases! :)

some lisps ignore the slot's :type declarations while others are rather strict about it. developing on one lisp may completely hide errors/warning that only show up as errors when tested on another lisp.

What I'm proposing is an opt-in feature: if you don't enable it, nothing changes. If you enable it, you get stricter typing. If a compiler reports an error, it's a feature: the type is wrong and should be fixed. In that sense, the slot `:type` option has the same impact as the other typing capabilities of the language (e.g. `(declaim (ftype ...))`).

- it also increases code complexity

Isn't this point the same as your first one? If we separate this function into smaller functions, the code would be much clearer.

and i suspect most people will not use this feature, or straight out don't even know that it exists if it's not on by default.

Well, we have a documentation! :)

complexity has a cost that is most often ignored. - whoever decides to specify the slot's type is better off doing it explicitly

They still can with my proposed change. To sum up, what this does in practice is _slot type inference_, which some programmers find useful: it adds some type checking for free (i.e. without additional code to write).

[Ambrevar]

I've updated the patch to disable type inference by default (it's now an opt-in feature).

[aartaka]

@Ambrevar, don't forget to propagate atlas-engineer/nyxt@c3778a2 to type inference here, as nil is often used as "nothing" slot value, not having any particular type to it. With this change in, I'd consider this feature quite complete and useful, given that we've been using it in Nyxt for more than a year now to control the types of slots and diagnose faulty code paths.

@attila-lendvai, I'd consider one year in an OO-heavy project a good test period for a feature that's otherwise addressing your concerns (given that type inference is off by default now, there's nothing else to worry about)!