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