Mark float and list (float) field types as no_ui

I guess this is a better component :)

Yeah I totally think that float not stored as doubles are pointless.

Not that we care, but the myth that floats are less to compute is actually wrong these days. CPUs use doubles native and need conversion before doing anything with floats.

I think we need someone from Drupal commerce to comment on this. I only see price field as a float.

No, prices are never floats. Decimal yes, but not float.

Price should be a decimal field.

They are using the float data type, not the float field type: https://github.com/commerceguys/commerce/blob/8.x-2.x/modules/price/src/...

I'm all for moving floats out of core, if that's something we're still ok with at this point.

As far as I can remember, floats went into D7 mostly because they were part of the cck pack. I agree that they mostly add confusion when choosing your field type, while the actual use cases are very non-80%. They are also kind of half-baked, for the same reason.

We'd need a volunteer to maintain them in contrib though :-)

I'm fine with this (fewer choices in that drop-down of DOOOOM the better), although not sure 100% why we're discussing it now.

...nor why it's major? I guess because there's a major bug with the Float upgrade path?

Prices must never be floats. The linked code is temporary and embarrassing.
In general, float fields should be used very carefully. You almost always want a decimal instead.

+1 to moving to contrib.

The fact that commerce is temporarily using the wrong datatype is a very good reason to move these to contrib.

@yched I think we should be prepared to move things out without a maintainer stepping up. Especially when it's something we're trying to remove from core because we want to discourage people from using it. Doesn't help people that are already using it of course, and hard to get any actual data on that.

we only have ListFloatItem and not ListDecimalItem

Oh crap, that's unfortunate. I don't even think I remember why that happened, we're probably talking CCK D5 :-/

Well, I guess turning ListFloatItem into ListDecimalItem would not be too hard... It does add to the "disruption" part though.

Updating the IS with some details.

This would have to happen in 9.1 now, for deprecation in Drupal 10, I think...

Although, just musing... rather than moving wholesale to contrib, do we instead want to make Float into a proper Decimal field, so it more cleanly matches user expectations? (e.g. I would expect a "Price" field to be something that 50%+ of sites would expect to be able to do with core, and would be very surprised when I got chastised by @bojanz ;) for choosing the one option in core that seemed to fit.)

do we instead want to make Float into a proper Decimal field

I think we already have a decimal field (it might not be proper), but this got me thinking, instead of moving to contrib, we could move 'float' to a separate module within core, then write an update hook to enable that module for any site that actually has float fields, and then disable the module by default on new installs. That way the decimal number would remain in the selection, but the confusing float would not.

once float was in it's own module, a proper 'double' precision type could also be added, which would avoid the confusion many have with float, but not bloat the default field type selector unnecessarily...

The above approach could presumably go into 8.x, 9.x, etc, given a proper change notice...

We we would need to do #24 (or very close) if we move the module to contrib too, so splitting it out is a good step regardless of where it ends up eventually. Moving back to 9.0.x.

Interesting idea. This would need product signoff. (#23 isn't so much a signoff as feedback/review.) At this point this would definitely be deprecate-in-D9-minors, remove-in-D10. So 9.1.x.

All you are saying is that drupal does not have proper number and calculation support until 9.1.?!
Are you sure?!

A year ago I had problems with the decimal field. It would not aggregate (if I remember correctly). So I moved them all to floats in order to be able to make simple calculations with decimals.
It worked up to some 8.x release very well. I realized with 8.8.5 (maybe the issue existed earlier - I couldn't say) that float is broken.

So the only number fields that can be used reliably are integers?!
8.8.5 is just a beta?

While this will need an upgrade path, it is not yet tied to a specific version.

I just created a number field on a site, and got the three options for integer, decimal, and float. Nearly opened a new issue to remove float then found this one.

Updated the issue summary with a proposed plan. The plugin is defined in core/lib, not in any module. I think the simplest way with this might be to create a new float module directly in contrib, and deprecate the core decimal plugin directly in core - i.e. without an interim step of moving the field to a module in core. This is because we don't only want to remove it from core but also we want to discourage people from using it on new sites.

If we try to move it to a module within core before moving it out, we'll need to enable that module on sites using the float field type, which means an upgrade path etc. - better to let those sites manually add a contrib module when they do a major upgrade (or any time before a major upgrade once the module is available).

Removing the upgrade path tag because I think we can do this without an actual update - just a module for sites to add from contrib if they use the field.

When updating the issue summary, I forgot we don't have #3039240: Create a way to declare a plugin as deprecated yet. Also if we only deprecate the plugin, it will still be in the UI for all Drupal 11 sites.

So it might be better to go the module route in core after all, this would look like:

1. Move the plugin and any test coverage to a new 'Float field' module.

2. Add an upgrade path, in system module, to install the module on any site that's using the float field.

3. Immediately/asap mark that module deprecated and do the other steps to move it to a contrib module.

I went through different contrib use cases for floats and I didn't really find good examples where float would be used correctly as a bundle field. There are examples of valid use cases where float is used as a base field. This doesn't mean someone couldn't be using it for the right reasons as a bundle field but by nature float is probably something that would be more likely to be used as base field for use cases like computations.

If float field type is a minimal maintenance feature for us, I'm wondering if we should keep float as a field type in core but start by marking it as no_ui: true? A contrib module could be then be added to add it to the Field UI for those that need it there.

I like the no_ui idea!

Let's try no_ui here. The main issue is the UX issue presenting these as choices in the field UI, saves us having to do the full module and deprecation route and doesn't prevent us from doing that later if there's a new reason to.

Removing the product review tag based on #38. Removing the subsystem maintainer review tag since removing the field type from UI is much less invasive than moving it to contrib.

Pushed a two-line MR to see what breaks, if anything.

lol, two more lines necessary to get things green, so four lines in total.

That's a lot easier than factoring out to a module and moving to contrib!

Added a change record and updated the issue summary.

Committed b23f427 and pushed to 11.x. Thanks!

I agree that this is a very rarely used feature, but it is sometimes used, http://codcontrib.hank.vps-private.net/search?text=field_type%3A%20float... has 3 pages of results (quite a lot are just tests). default config of course still works, just linked to that for use cases.

Unlike an optional module that non-developers can install, the no_ui flag requires that you implement an alter hook to be able to still add them through the UI.

As a compromise, I added an untested example hook to revert this, if someone creates a module for doing that they can share it there.

Not mentioned here but we discussed on Slack that it would be simple to create a module for this. We could add that to the CR in case that someone wants to create that.

Amending attribution.

@renat created a module (code is still missing as I write this) to reenable Number Float:

https://www.drupal.org/project/reenable_number_float

The module description makes it a good case on showing the Number Float again, instead of hiding it under the carpet.

@xmacinfo Thanks for surfacing this! The code has now been added to the referenced module to re‑enable Number (float).

I do agree that the decimal field type is almost always preferable to float—provided we can actually make decimals work by resolving issue #2230909.

Given the number of core contributors and maintainers following this thread, would it make sense to open a focused follow‑up? Alternatively, could a respected community member define the absolute minimal requirements needed to commit the fix for #2230909 so we can finally move it forward? This is a triaged, core‑major issue that has been open for 11 years, leaves the decimal field type barely usable in practice, and has had a working patch for years that keeps stalling over nice‑to‑haves rather than must‑haves. Probably the priority should be to make the decimal field operational now; and anything beyond what is strictly necessary for this patch should go into a follow‑up?