Upon reading this, It triggered an idea.
>
> On Saturday, 30 September 2017 at 16:10:44 UTC, Jonathan Marler wrote:
>> https://wiki.dlang.org/DIP88
>>
>> I'd like to see DIP88 (Named Parameters) revived.  Was this proposal rejected or is it just stale and needs a refresh?  Named parameters can be implemented in a library, however, in my opinion they are useful enough to warrant a clean syntax with language support.  I'd be willing to refresh the DIP so long as I know the idea has not already been rejected.

DIP reminds me of object destruction.

/* extracts success & message from returned type. Could be tuple or structure, etc. May even eliminate use of tuples for multiple return
*/

auto {success, message} = callVoldermortFunction();

 This is concept is used in Kotlin. JavaScript es6 takes it even further (function parameters and arguments support object destruction)

On Wednesday, 4 October 2017 at 10:03:56 UTC, aberba wrote:
> auto {success, message} = callVoldermortFunction();

❤❤❤❤❤ I want this syntax, plz! This solves the issue how to return multiple ref values. --Ilya

On Wednesday, 4 October 2017 at 10:03:56 UTC, aberba wrote:
>  Upon reading this, It triggered an idea.
>>
>> On Saturday, 30 September 2017 at 16:10:44 UTC, Jonathan Marler wrote:
>>> [...]
>
> DIP reminds me of object destruction.
>
> /* extracts success & message from returned type. Could be tuple or structure, etc. May even eliminate use of tuples for multiple return
> */
>
> auto {success, message} = callVoldermortFunction();
>
>  This is concept is used in Kotlin. JavaScript es6 takes it even further (function parameters and arguments support object destruction)

+1

On Wednesday, 4 October 2017 at 10:03:56 UTC, aberba wrote:
>  Upon reading this, It triggered an idea.
>>
>> On Saturday, 30 September 2017 at 16:10:44 UTC, Jonathan Marler wrote:
>>> https://wiki.dlang.org/DIP88
>>>
>>> I'd like to see DIP88 (Named Parameters) revived.  Was this proposal rejected or is it just stale and needs a refresh?  Named parameters can be implemented in a library, however, in my opinion they are useful enough to warrant a clean syntax with language support.  I'd be willing to refresh the DIP so long as I know the idea has not already been rejected.
>
> DIP reminds me of object destruction.
>
> /* extracts success & message from returned type. Could be tuple or structure, etc. May even eliminate use of tuples for multiple return
> */
>
> auto {success, message} = callVoldermortFunction();
>
>  This is concept is used in Kotlin. JavaScript es6 takes it even further (function parameters and arguments support object destruction)

People often call this "destructuring" or "unpacking" to avoid confusion with destructors.

On Wednesday, 4 October 2017 at 12:06:43 UTC, John Colvin wrote:
> [...]
>
> People often call this "destructuring" or "unpacking" to avoid confusion with destructors.

Or "Structured Bindings" ;)
http://en.cppreference.com/w/cpp/language/structured_binding

On 10/04/2017 05:06 AM, John Colvin wrote:

> People often call this "destructuring"

Thanks! Now it makes sense. :)

Ali

On Wednesday, 4 October 2017 at 12:06:43 UTC, John Colvin wrote:
> On Wednesday, 4 October 2017 at 10:03:56 UTC, aberba wrote:
>>  Upon reading this, It triggered an idea.

> People often call this "destructuring" or "unpacking" to avoid confusion with destructors.

Thats the word I was looking for. Ha ha

On 04.10.2017 12:03, aberba wrote:
>   Upon reading this, It triggered an idea.
>>
>> On Saturday, 30 September 2017 at 16:10:44 UTC, Jonathan Marler wrote:
>>> https://wiki.dlang.org/DIP88
>>>
>>> I'd like to see DIP88 (Named Parameters) revived.  Was this proposal rejected or is it just stale and needs a refresh? Named parameters can be implemented in a library, however, in my opinion they are useful enough to warrant a clean syntax with language support.  I'd be willing to refresh the DIP so long as I know the idea has not already been rejected.
> 
> DIP reminds me of object destruction.
> 
> /* extracts success & message from returned type. Could be tuple or structure, etc. May even eliminate use of tuples for multiple return
> */
> 
> auto {success, message} = callVoldermortFunction();
> 
>   This is concept is used in Kotlin. JavaScript es6 takes it even further (function parameters and arguments support object destruction)
> 
> 

Why curly braces? Multiple function arguments are a form of built-in tuple, so the syntax should be consistent:

auto (success, message) = callVoldemortFunction();

The only unresolved question is (as using the result of the comma operator has been deprecated already): How to write a unary tuple. My favourite is what python does: "(3,)". This is however already accepted as a function argument list. I think it is worth breaking though. Maybe we should deprecate it.

On Thursday, 5 October 2017 at 06:42:14 UTC, Timon Gehr wrote:
> On 04.10.2017 12:03, aberba wrote:
>>   Upon reading this, It triggered an idea.
>>>
>>> On Saturday, 30 September 2017 at 16:10:44 UTC, Jonathan Marler wrote:
>>>> [...]
>> 
>> DIP reminds me of object destruction.
>> 
>> /* extracts success & message from returned type. Could be tuple or structure, etc. May even eliminate use of tuples for multiple return
>> */
>> 
>> auto {success, message} = callVoldermortFunction();
>> 
>>   This is concept is used in Kotlin. JavaScript es6 takes it even further (function parameters and arguments support object destruction)
>> 
>> 
>
> Why curly braces? Multiple function arguments are a form of built-in tuple, so the syntax should be consistent:
>
> auto (success, message) = callVoldemortFunction();


I think I can state the opinion of many D users here: I don't mind whether it will be curly braces or round parentheses - the important thing is that we will be able to use it in the foreseeable future :)

> The only unresolved question is (as using the result of the comma operator has been deprecated already): How to write a unary tuple. My favourite is what python does: "(3,)". This is however already accepted as a function argument list. I think it is worth breaking though. Maybe we should deprecate it.

+1

On 10/5/17 2:42 AM, Timon Gehr wrote:

> The only unresolved question is (as using the result of the comma operator has been deprecated already): How to write a unary tuple. My favourite is what python does: "(3,)". This is however already accepted as a function argument list. I think it is worth breaking though. Maybe we should deprecate it.

I know you have an answer for this, but pardon my ignorance. Why isn't (a) good enough?

-Steve