preparing for named arguments
aliak
something at something.com
Tue Aug 27 07:21:37 UTC 2019
On Tuesday, 27 August 2019 at 02:09:55 UTC, rjframe wrote:
> On Mon, 26 Aug 2019 22:19:38 +0000, aliak wrote:
>> [...]
>
> I can't see any place where I'd use the parameter name for a
> range, so r/ range/r1/etc. wouldn't matter. My range variable
> name is the documentation, or it's a literal array in a
> unittest. Based on what I've read of others' code, that's
> typical; and range functions tend to be small and named for
> what they do, so are self-documenting.
>
> ---
> arr = myRange.sort!((a, b) => a > b)
> .takeExactly(10) // .takeExactly(number: 10) doesn't aid
> readability,
> .group // so why bother?
> .assocArray;
> ---
>
> Most of the time in other languages a named parameter will
> document a literal argument or allow skipping parameters with
> default values. It would be a good idea to skim Phobos to
> name-check, but I don't think it will require a really large
> number of renames since most parameters realistically won't be
> passed via their names.
>
> --Ryan
1) I agree about ranges, most will probably just use it in a way
that it doesn't matter
2) But, if there's a feature it will be used. Always.
3) Won't hurt to make the arguments even for ranges consistent.
More information about the Digitalmars-d
mailing list