Discussion Thread: DIP 1030--Named Arguments--Final Review

[Jonathan Marler]

On Wednesday, 13 May 2020 at 08:17:26 UTC, Jacob Carlborg wrote:
> On 2020-05-12 08:22, Jonathan Marler wrote:
>> A sleep function that takes milliseconds on the other hand 
>> could be helpful:
>> 
>> sleep(100);
>> sleep(msecs:100); // helpful
>
> I disagree. It's much better what we already have. The `sleep` 
> method on `Thread` takes a duration, instead of a specific time 
> unit. The duration is also encoded in its own type:
>

Yes I also agree that what we have in phobos is already better 
than this.  I was just showing an example of a theoretical sleep 
function that already took a integer value of milliseconds.  This 
was a poor example on my part.

>> Given that, here are a list of conventions:
>>
>> 2. Common generic parameter names
>> 
>> p (generic pointer argument, prefer this over ptr or pointer)
>> s (generic string argument, prefer this over str or string)
>> i (generic integer argument)
>
> I disagree. I think there are very few cases of APIs where a 
> function expects a truly generic value. It's better to try to 
> encode the purpose or how a value is used in the parameter 
> name. Naming something based on what it is rarely useful, we 
> have a much better system for that, which is the type system 
> :). For example:
>

Good point, if we defer to the first rule, there may be no need 
to have a convention for generic parameters like these.

>> msecs
>> secs
>
> Same thing as the `sleep` method. Should not be a plain int, 
> should be its own type.

When we can yes.  However the C sleep function does take an 
integer, in which case we can use the parameter name for 
clarification.

https://linux.die.net/man/3/sleep
extern "C" uint sleep(uint seconds);

sleep(2);
sleep(seconds:2);


>
> Also, we should avoiding having short, abbreviated symbol names 
> (any kind of symbol names, not just parameter names). Although 
> it's worse to have abbreviated names which are part of the API 
> or show up in generated documentation. There are always 
> exceptions, like when abbreviated name is more known and common 
> than the actual full name. Examples are: HTTP, FTP and so on.

Yeah these are the types of things I think we should discuss, 
especially for the standard library before we enable this feature.