On Monday, 16 October 2017 at 23:29:46 UTC, sarn wrote:
On Sunday, 15 October 2017 at 15:19:21 UTC, Q. Schroll wrote:
On Saturday, 14 October 2017 at 23:20:26 UTC, sarn wrote:
On Saturday, 14 October 2017 at 22:20:46 UTC, Q. Schroll
wrote:
Therefore, and because of brackets, you can distinguish
On Sunday, 15 October 2017 at 15:19:21 UTC, Q. Schroll wrote:
On Saturday, 14 October 2017 at 23:20:26 UTC, sarn wrote:
On Saturday, 14 October 2017 at 22:20:46 UTC, Q. Schroll wrote:
Therefore, and because of brackets, you can distinguish f(1,
2) from f([1, 2]).
But in f([1, 2]), it's ambigu
On Saturday, 14 October 2017 at 23:20:26 UTC, sarn wrote:
On Saturday, 14 October 2017 at 22:20:46 UTC, Q. Schroll wrote:
Therefore, and because of brackets, you can distinguish f(1,
2) from f([1, 2]).
But in f([1, 2]), it's ambiguous (just by parsing) whether [1,
2] is a tuple literal or a d
Sorry for waiting so long to respond, I had to think about this a lot...
On 10/12/17 3:05 PM, Timon Gehr wrote:
On 10.10.2017 17:05, Steven Schveighoffer wrote:
On 10/9/17 11:22 AM, Timon Gehr wrote:
On 09.10.2017 01:20, Steven Schveighoffer wrote:
My questioning comes with this:
void bar(i
On Saturday, 14 October 2017 at 22:20:46 UTC, Q. Schroll wrote:
Therefore, and because of brackets, you can distinguish f(1, 2)
from f([1, 2]).
But in f([1, 2]), it's ambiguous (just by parsing) whether [1, 2]
is a tuple literal or a dynamic array literal.
You'd need to use a prefix or somet
I've thought about tuples and stuff for a while. For tuples, I'll
use [brackets]. Reasons follow.
Homogeneous tuples are repetitions of some single type. We have
them today in form of static arrays. We could allow
"inhomogeneous arrays" and call them tuples. T[n] is then an
alias for [T, T, .
On 10.10.2017 17:05, Steven Schveighoffer wrote:
On 10/9/17 11:22 AM, Timon Gehr wrote:
On 09.10.2017 01:20, Steven Schveighoffer wrote:
My questioning comes with this:
void bar(int a);
void bar((int,) x);
To me, it is confusing or at least puzzling that these two aren't the
same.
...
We
On 10/9/17 11:22 AM, Timon Gehr wrote:
On 09.10.2017 01:20, Steven Schveighoffer wrote:
My questioning comes with this:
void bar(int a);
void bar((int,) x);
To me, it is confusing or at least puzzling that these two aren't the
same.
...
Well, to me it is a bit confusing that this is puzzl
On Monday, 9 October 2017 at 15:22:35 UTC, Timon Gehr wrote:
Singleton tuples might seem pointless, and some languages do
not support such single-element tuples, but as we want to
support slicing, they should probably exist. (Also, we might
want to create a tuple from an AliasSeq, which can b
On 09.10.2017 01:20, Steven Schveighoffer wrote:
On 10/7/17 8:56 PM, Timon Gehr wrote:
On 06.10.2017 23:34, Steven Schveighoffer wrote:
No. All functions take one argument and produce one result. (The
argument and the result may or may not be a tuple, but there is no
essential difference b
On 10/7/17 8:56 PM, Timon Gehr wrote:
On 06.10.2017 23:34, Steven Schveighoffer wrote:
No. All functions take one argument and produce one result. (The
argument and the result may or may not be a tuple, but there is no
essential difference between the two cases.) You can match a value
agai
On 06.10.2017 23:34, Steven Schveighoffer wrote:
No. All functions take one argument and produce one result. (The
argument and the result may or may not be a tuple, but there is no
essential difference between the two cases.) You can match a value
against a pattern on the function call.
I
On 10/6/17 3:31 PM, Timon Gehr wrote:
On 06.10.2017 14:26, Steven Schveighoffer wrote:
On 10/5/17 3:42 PM, Timon Gehr wrote:
On 05.10.2017 17:40, Steven Schveighoffer wrote:
On 10/5/17 2:42 AM, Timon Gehr wrote:
The only unresolved question is (as using the result of the comma
operator has b
On Friday, 6 October 2017 at 19:51:39 UTC, Timon Gehr wrote:
No, under my thinking the original example should have been
what it was.
Enclosing an expression in an additional set of parentheses
does not change its semantics. This is true even if one set of
parentheses is part of the function ca
On 06.10.2017 21:43, jmh530 wrote:
On Friday, 6 October 2017 at 19:31:11 UTC, Timon Gehr wrote:
The proposal is to make all arguments "single type arguments". The
"single type" might be a tuple. A tuple type is just a type, after
all. For two current functions where only one matches but after t
On Friday, 6 October 2017 at 19:31:11 UTC, Timon Gehr wrote:
The proposal is to make all arguments "single type arguments".
The "single type" might be a tuple. A tuple type is just a
type, after all. For two current functions where only one
matches but after the change both would match, the sam
On 06.10.2017 14:26, Steven Schveighoffer wrote:
On 10/5/17 3:42 PM, Timon Gehr wrote:
On 05.10.2017 17:40, Steven Schveighoffer wrote:
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
On 10/5/17 3:42 PM, Timon Gehr wrote:
On 05.10.2017 17:40, Steven Schveighoffer wrote:
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: "
On Thursday, 5 October 2017 at 15:23:26 UTC, Seb wrote:
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 :)
All my +1s. Let's leave syntax de
On Thursday, 5 October 2017 at 19:55:15 UTC, Timon Gehr wrote:
The reason why back then it seemed as if it "can't be used" is
that it was taken by the comma operator. This is no longer the
case.
Fair enough. I only didn't have an issue with it because I had
recalled it when reading the prev
On 05.10.2017 17:48, jmh530 wrote:
On Thursday, 5 October 2017 at 06:42:14 UTC, Timon Gehr wrote:
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 i
On 05.10.2017 17:23, Seb wrote:
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
On 05.10.2017 17:40, Steven Schveighoffer wrote:
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
accepte
On Thursday, 5 October 2017 at 06:42:14 UTC, Timon Gehr wrote:
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
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
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 fro
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 refr
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.
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:
[...]
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 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 ju
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 stru
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
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 imple
34 matches
Mail list logo
