Jump to page: 1 24  
Page
Thread overview
Proposal: Object/?? Destruction
Oct 04
aberba
Oct 04
SrMordred
Oct 04
bitwise
Oct 04
aberba
Oct 05
Seb
Oct 05
sarn
Oct 06
jmh530
Oct 06
jmh530
Oct 09
jmh530
Oct 14
sarn
6 days ago
Q. Schroll
5 days ago
sarn
Oct 05
jmh530
Oct 05
jmh530
October 04
 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)


October 04
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

October 04
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
October 04
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.
October 04
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


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

> People often call this "destructuring"

Thanks! Now it makes sense. :)

Ali

October 04
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
October 05
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.
October 05
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
October 05
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
« First   ‹ Prev
1 2 3 4