From 1521c72b5937977437b3fb43773d84920c602df1 Mon Sep 17 00:00:00 2001 From: mihaicalinluca Date: Thu, 9 Nov 2023 13:12:53 +0100 Subject: [PATCH] fix after review --- docs/developers/data/multi-values.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/developers/data/multi-values.md b/docs/developers/data/multi-values.md index a87dfb54..5cdb750b 100644 --- a/docs/developers/data/multi-values.md +++ b/docs/developers/data/multi-values.md @@ -40,13 +40,13 @@ Another scenario to consider involves the use of multiple `Option` arguments. Ta ```rust #[endpoint(myOptionalEndpoint)] -fn my_optional_endpoint(&self, first_arg: Option, second_arg: Option) +fn my_optional_endpoint(&self, first_arg: OptionalValue, second_arg: OptionalValue) ``` In this context, both arguments (or none) should be provided at the same time in order to get the desired effect. Since arguments are processed sequentially from left to right, supplying a single value will automatically assign it to the first argument, making it impossible to determine which argument should receive that value. -The same rule applies when any regular argument is placed after a var-arg, so we have enforced a strong restriction regarding arguments' order. Regular arguments `must not` be placed after var-args. +The same rule applies when any regular argument is placed after a var-arg, thus, a strong restriction regarding arguments' order has been enforced. Regular arguments `must not` be placed after var-args. -To further enhance clarity and minimize potential errors related to var-args, starting from framework version `v0.44.0`, we have introduced a new annotation called `#[allow_multiple_var_args]`. +To further enhance clarity and minimize potential errors related to var-args, starting from framework version `v0.44.0`, it is no longer allowed by default to have multiple var-args. This restriction can be lifted by using the #[allow_multiple_var_args] annotation. :::info Note `#[allow_multiple_var_args]` is required when using more than one var-arg in an endpoint and is placed at the endpoint level, alongside the `#[endpoint]` annotation. Utilizing `#[allow_multiple_var_args]` in any other manner will not work. @@ -55,11 +55,11 @@ Considering this, our optional endpoint from the example before becomes: ```rust #[allow_multiple_var_args] #[endpoint(myOptionalEndpoint)] -fn my_optional_endpoint(&self, first_arg: Option, second_arg: Option) +fn my_optional_endpoint(&self, first_arg: OptionalValue, second_arg: OptionalValue) ``` ::: -The only parsing validations are taking into account the number of var-args and their position. Not having `#[allow_multiple_var_args]` as an endpoint attribute if the endpoint is using more than one var-arg and/or placing regular arguments after var-args will fail the build. +The absence of #[allow_multiple_var_args] as an endpoint attribute, along with the use of multiple var-args and/or the placement of regular arguments after var-args, leads to build failure, as the parsing validations now consider the count and positions of var-args. However, when `#[allow_multiple_var_args]` is used, there is no other parsing validation (except the ones from above) to enforce the var-args rules mentioned before. In simpler terms, using the annotation implies that the developer is assuming responsibility for handling multiple var-args and anticipating the outcomes, effectively placing trust in their ability to manage the situation.