do we need NoArgs?

[pyo3]

do we need NoArgs?

[messense]

If we add a

impl<T: IntoPyTuple> IntoPyTuple for Option<T> {
    fn into_tuple(self, py: Python) -> Py<PyTuple> {
        match self {
            Some(v) => v.into_tuple(py),
            None => PyTuple::empty(py)
        }
    }
}

We can use None instead of NoArgs

[fafhrd91]

Super! Let's do that

[messense]

Unfortunately

error[E0282]: type annotations needed
   --> tests/test_class.rs:118:26
    |
118 |     assert!(typeobj.call(None, None).unwrap().cast_as::<EmptyClassWithNew>().is_ok());
    |                          ^^^^ cannot infer type for `T`

error: aborting due to previous error(s)

call(args, kwargs) can't use None as args because into_typle can't infer type for T (None is a variant of Option while NoArgs is a struct). So we stuck with () or NoArgs.

[fafhrd91]

What if you use NoArgs as T?

[fafhrd91]

Ah, nevermind

[fafhrd91]

is it possible to use default generic type parameter?

[messense]

I am not sure what you mean by default generic type parameter.

[fafhrd91]

https://github.com/rust-lang/rust/blob/master/src/test/run-pass/generic-default-type-params.rs

[fafhrd91]

rust-lang/rust#26870

[messense]

default generic type parameter seems only allowed in type declaration now.

error: defaults for type parameters are only allowed in `struct`, `enum`, `type`, or `trait` definitions.
   --> src/objectprotocol.rs:250:13
    |
250 |     fn call<A = ()>(&self, args: A, kwargs: Option<&PyDict>) -> PyResult<&PyObjectRef>
    |             ^
    |
    = note: #[deny(invalid_type_param_default)] on by default
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #36887 <https://github.com/rust-lang/rust/issues/36887>

error: aborting due to previous error(s)

error: Could not compile `pyo3`.

rust-lang/rust#36887

[messense]

If we change call signature to

fn call<A>(&self, args: A, kwargs: Option<&PyDict>) -> PyResult<&PyObjectRef>
    where A: Into<Option<Py<PyTuple>>>

Use should be able to pass None, Some(PyTuple::xxx) and PyTuple::xxx since Option has the following impl since 1.12.0:

impl<T> From<T> for Option<T>

https://doc.rust-lang.org/src/core/option.rs.html#854-858

But that would require user to provide a PyTuple object.

[fafhrd91]

I think it would reduce usability. i use IntoPyTuple much more often, plus NoArg is not big deal

[fafhrd91]

we can play with associated types, similar to class protocols. but I am not sure if it could be implemented

[fafhrd91]

lets close this issue, NoArgs is not priority at the moment.