CC @honno

However, this seems to have been a mistake, as scalar values do not have an array data type (only int or float) and do not participate in type promotion.

FWIW, this matched the behavior of full(), which infers the data type from fill_value when dtype=None.

@asmeurer Correct, but full_like has the advantage of additional information needed to make a better guess as to the desired output array data type. So full should probably not serve as a basis for full_like.

Also, just to clarify, for all the *_like functions, the dtype of x should be completely ignored if dtype is provided, even if it isn't compatible? For instance, ones_like(array(..., dtype=bool), dtype=int8) (this was another point that came up in data-apis/array-api-tests#18).

Also, just to clarify, for all the *_like functions, the dtype of x should be completely ignored if dtype is provided, even if it isn't compatible?

Yes, it should be ignored. Compatibility does not apply for the *_like functions, as the functions infer meta data about the array and do nothing with the actual values of x themselves.

I will update the guidance in a separate PR, however, to make this a bit more explicit.

This has been approved and simply reverts to previous behavior. Merging...