# \[Pre-RFC\] named arguments

**URL:** <https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831>\
**Category:** language design\
**Created:** [August 8, 2016, 9:57am UTC](https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831 "2016-08-08T09:57:08Z")\
**Posts on this page:** 1\
**Showing post:** 86

<div class="post-metadata">

**Author:** ![Keats](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/keats/32/1715_2.png) [@Keats](https://internals.rust-lang.org/u/Keats)\
**Post date:** [August 10, 2016, 1:37pm UTC](https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831/86 "2016-08-10T13:37:40Z")

</div>

> [@jjpe](#):
>
> ```rust
> let = p Point::new()
> .x0(0)
> .x1(10)
> .x2(100);
> 
> ```

I would say this syntax is objectively worse than with kwargs. Not everything is a struct instantiation. To quote a previous example:

```rust
// might have headers etc as optional options
http.get("https://www.rust-lang.org/en-US/", timeout: None);

```

Using a builder pattern would mean changing the API to be quite ugly imo:

```rust
let req = HttpRequest::new("https://www.rust-lang.org/en-US/")
   .method(Method::GET)
   .timeout(None)
   .exec();

```

Another disadvantage of the builder pattern is that you need to implement a fn for each field which can mean lots of code for not much reason.

I would say named arguments (and default args) are one of the main reasons Python libraries like requests or even pandas are so elegant. Making something like [http://pandas.pydata.org/pandas-docs/stable/generated/pandas.read\_csv.html](http://pandas.pydata.org/pandas-docs/stable/generated/pandas.read_csv.html) simple for both library author and users is quite impressive.

I would say that named arguments really shine when combined with default args though.

---

_[View the full topic](https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831)._