Equally condescending is saying "It's great that you like X, but I don't so I'm going to ignore the broader point of your argument."

The point remains that the fact a given parameter's valid values are [0,1] is not a function of it's name. You can check the values within the method and enter various error states depending on the exact business rules.

"your question is wrong" is indeed unhelpful, especially as a direct response to someone asking a question.

"here is what seems like a better question" is helpful, especially in a discussion forum separate from the original Q/A.

But if "here is what seems like a better question" is the _only_ response or drowns out direct responses, then thats still frustrating.

> condescending

As a man who sometimes lacks knowledge about things, when I ask a question, please please please err on the side of condescending to me rather than staying silent. (No, I don't know how you should remember my preferences separately from the preferences of any other human)

I'm genuinely sorry if I came across as condescending, that was not my intention at all.

I merely wanted to point out that, in my opinion, this property should be reflected in parameter type, rather than the name. Just like, if we wanted a parameter that should only be a whole number, we wouldn't declare it as a float and name it "MyVariableInteger" and hope that the callers would only send integers.

You mentioned that there are quite a few languages that do not permit what I proposed, would you mind specifying which ones exactly? The only one that comes to my mind is assembly?

So, then the user calling the library with foo(3.5) will get a runtime error (or, ok, maybe even a compile time error).

To avoid that, you need to document that the value should be between 0 and 1, and you could do that with a comment line (which the OP wanted to avoid), or by naming the variable or type appropriately: And that takes us back to the original question. (Whether the concept is expressed in the parameter name or parameter type (and its name) is secondary.)

> So, then the user calling the library with foo(3.5) will get a runtime error (or, ok, maybe even a compile time error).

I'm not sure I understand this. See below, but the larger point here is that the type can never lie -- names can and often do because there's no checking on names.

I think what is being proposed is something similar to

    newtype Accuracy = Accuracy Float

and then to have the only(!) way to construct such a value be a function

    mkAccuracy :: Float -> Maybe Accuracy

which does the range checking, failing if outside the allowable range.

Any functions which needs this Accuracy parameter then just take a parameter of that type.

That way you a) only have to do the check at the 'edges' of your program (e.g. when reading config files or user input), and b) ensure that functions that take an Accuracy parameter never fail because of out-of-range values.

It's still a runtime-check, sure, but but having a strong type instead of just Float, you can ensure that you only need that checking at the I/O edges of your program and absolute assurance that any Accuracy handed to a function will always be in range.

You can do a similar thing in e.g. C with a struct, but unfortunately I don't think you can hide the definition such that it's impossible to build an accuracy_t without going through a "blessed" constructor function. I guess you could do something with a struct containing a void ptr where only the implementation translation unit knows the true type, but for such a "trivial" case it's a lot of overhead, both code-wise and because it would require heap allocations.

You're solution is the ideal one and safest, although in the interest of maximum flexibility since the goal here seems more documentative than prescriptive, it could also be as simple as creating a type alias. In C for example a simple `#define UnitInterval float`, and then actual usage would be `function FuncName(UnitInterval accuracy)`. That accomplishes conveying both the meaning of the value (it represents accuracy) and the valid value range (assuming of course that UnitInterval is understood to be a float in the range of 0 to 1).

Having proper compile time (or runtime if compile time isn't feasible) checks is of course the better solution, but not always practical either because of lack of support in the desired language, or rarely because of performance considerations.

That's fair, but I do personally have a stance that compiler-checked documentation is the ideal documentation because it can never drift from the code. (EDIT: I should add: It should never be the ONLY documentation! Examples, etc. matter a lot!)

There's a place for type aliases, but IMO that place is shrinking in most languages that support them, e.g. Haskell. With DerivingVia, newtypes are extremely low-cost. Type aliases can be useful for abbreviation, but for adding 'semantics' for the reader/programmer... not so much. Again, IMO. I realize this is not objective truth or anything.

Of course, if you don't have newtypes or similarly low-cost abstractions, then the valuation shifts a lot.

EDIT: Another example: Scala supports type aliases, but it's very rare to see any usage outside of the 'abbreviation' use case where you have abstract types and just want to make a few of the type parameters concrete.

so, basically hungarian notation

'disingenuous' seems to imply that it was an intentional omission. -- which i doubt it was.

you have a very valid point but it would come across even more effectively without that part, i believe.

Sure, such other languages have the problem too, it's just that they are missing the best solution. It's possible for a solution to be simultaneously bad and the best available.