This could cause problems for Libre-SOC, since we use reset_less in quite a few places, including tons where the signals are combinatorially driven.

@programmerjake Could you explain how LibreSOC uses reset_less comb signals? If there isn't a more idiomatic way to do what you need, I'm going to abandon this idea and update the (in-progress) language guide to explain that it's sometimes necessary.

In lots of the constructors for different data types, we set reset_less there, those constructors don't have an option to skip setting reset_less. Those data types are then used for both sync and comb logic.

Do you have a specific example?

https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/fpcommon/packdata.py;h=40cd7e1821a5a76495a1e3a104ce59fb488b03a6;hb=HEAD

That's the type used as the output data type of several different pipeline stages, where there's a combinatorial block that assigns the member Signals the correct values, that combinatorial block is then used from a completely generic class that creates more instances of the type and uses them for the pipeline registers, showing you where it's used would be pretty complex because we have multiple layers of generic code.

OK, that's reasonable. Let's commit to reset_less being ignored on combinatorial signals, then.