On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu
wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps tuples. So I started
with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I
On 09/24/2012 11:55 AM, Caligo wrote:
If tuples are ever introduced, I hope parentheses will not be used.
I would prefer something like this:
tuple2,1,8
Not using parentheses: a possibly valid idea!
Using angle brackets: never going to happen.
People HATE angle brackets. There is
On 09/23/2012 04:40 PM, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I
On 2012-09-28 19:09, deadalnix wrote:
It is ambiguous with the comma declaration syntax.
I could live without it.
--
/Jacob Carlborg
Le 28/09/2012 00:39, ixid a écrit :
int, string a = 1, hello;
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), hello;
}
This is incompatible with current language specs (or will ends up with
highly bizantine rules do define what to do, in a topic where it is
already
int a, int b = 3, 3;
Considering how the syntax is defined, this will not do what
you expect, and it is not fixable easily without breaking other
constructs.
I thought we'd already covered that part, that was what I agreed
would break far too much code. That is not the heart of the
Le 27/09/2012 00:38, bearophile a écrit :
Jonathan M Davis:
It sounds to me like the reason that structural typing is needed is
because
Tuple allows you to name its fields, which I've always thought was a
bad idea,
I have appreciated named fields of D tuples since the beginning, I have
found
Le 27/09/2012 08:17, Jacob Carlborg a écrit :
On 2012-09-27 00:38, bearophile wrote:
I have appreciated named fields of D tuples since the beginning, I have
found them quite handy. With them sometimes you don't need to unpack a
tuple, you can just access its fields with a nice name, avoiding
On 2012-09-27 00:38, bearophile wrote:
I have appreciated named fields of D tuples since the beginning, I have
found them quite handy. With them sometimes you don't need to unpack a
tuple, you can just access its fields with a nice name, avoiding to move
around more than one variable.
If you
On Wednesday, 26 September 2012 at 21:31:13 UTC, Jonathan M Davis
wrote:
On Wednesday, September 26, 2012 21:54:44 foobar wrote:
Library tuples have broken semantics.
Tuples supposed to have _structural_ typing which AFAIK can
only
be correctly implemented in language.
import
On Wednesday, 26 September 2012 at 23:02:45 UTC, Piotr Szturmaj
wrote:
Jonathan M Davis wrote:
It sounds to me like the reason that structural typing is
needed is because
Tuple allows you to name its fields, which I've always thought
was a bad idea,
and which a built-in tuple definitely
On Thursday, September 27, 2012 11:37:10 foobar wrote:
I do _not_ want to consider two different _structs_ (nominal
types) as the same type. I would like to get correct tuple
semantics which means _structural_ typing (I thought I emphasized
that enough in the OP).
A tuple is defined by its
On Wed, 26 Sep 2012 15:54:44 -0400, foobar f...@bar.com wrote:
On Tuesday, 25 September 2012 at 21:02:49 UTC, Andrei Alexandrescu wrote:
I agree. That's why I want to take the minimum amount of steps to make
library tuples work. That minimum amount may be 1, i.e. just implement
On Thursday, 27 September 2012 at 10:58:12 UTC, Jonathan M Davis
wrote:
On Thursday, September 27, 2012 11:37:10 foobar wrote:
I do _not_ want to consider two different _structs_ (nominal
types) as the same type. I would like to get correct tuple
semantics which means _structural_ typing (I
On Wednesday, 26 September 2012 at 12:20:56 UTC, Dmitry Olshansky
wrote:
On 25-Sep-12 23:29, kenji hara wrote:
My suggestion is very simple.
1. Change all words built-in tuple in the documentation to
built-in
sequence. Then, in the D language world, we can have clarify
name for
the built-in
int, string a = 1, hello;
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), hello;
}
This is incompatible with current language specs (or will ends
up with highly bizantine rules do define what to do, in a topic
where it is already complex).
Which parts exactly are
Le 25/09/2012 22:55, Nick Sabalausky a écrit :
On Tue, 25 Sep 2012 12:07:33 +0200
deadalnixdeadal...@gmail.com wrote:
Le 25/09/2012 09:11, Jacob Carlborg a écrit :
On 2012-09-25 00:28, bearophile wrote:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
What about:
||
|1|
|1, 2|
Yeah and why not þ1, 2þ
Le 25/09/2012 23:34, ixid a écrit :
You've shown it's clearly incompatible with the current language
and would break lots of code. What would it break if assignment
required explicit tuple brackets?
(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be
filled in order by the multiple
On 25-Sep-12 23:29, kenji hara wrote:
My suggestion is very simple.
1. Change all words built-in tuple in the documentation to built-in
sequence. Then, in the D language world, we can have clarify name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
template
Also, I want to add that type declarations should be changed
from statements to expressions so that we could do:
auto tup = (3, hello);
(int num, string s) = tup; // num == 3, s == hello
+1.
or
int num;
string s;
auto tup = (3, hello);
(num, s) = tup;
or like x++ containers
On Tuesday, 25 September 2012 at 21:02:49 UTC, Andrei
Alexandrescu wrote:
I agree. That's why I want to take the minimum amount of steps
to make library tuples work. That minimum amount may be 1, i.e.
just implement deconstruction.
Andrei
Library tuples have broken semantics.
Tuples
On Wednesday, September 26, 2012 21:54:44 foobar wrote:
Library tuples have broken semantics.
Tuples supposed to have _structural_ typing which AFAIK can only
be correctly implemented in language.
import std.typecons.TypeTuple;
struct MyTuple(T...)() {}
auto libTup = tuple(123, hello);
Jonathan M Davis:
So, this really makes no sense to me at all.
I agree that foobar examples aren't so good. But it's true that
Tuple() gives some troubles regarding missed structural typing:
import std.stdio, std.typecons;
alias Tuple!(float, float) T1;
alias Tuple!(float,x, float,y) T2;
On Thursday, September 27, 2012 00:05:41 bearophile wrote:
Jonathan M Davis:
So, this really makes no sense to me at all.
I agree that foobar examples aren't so good. But it's true that
Tuple() gives some troubles regarding missed structural typing:
import std.stdio, std.typecons;
Jonathan M Davis:
It sounds to me like the reason that structural typing is
needed is because
Tuple allows you to name its fields, which I've always thought
was a bad idea,
I have appreciated named fields of D tuples since the beginning,
I have found them quite handy. With them sometimes
I have appreciated named fields of D tuples since the
beginning, I have found them quite handy. With them sometimes
you don't need to unpack a tuple, you can just access its
fields with a nice name, avoiding to move around more than one
variable.
In Haskell to solve this problem there is the
Jonathan M Davis wrote:
It sounds to me like the reason that structural typing is needed is because
Tuple allows you to name its fields, which I've always thought was a bad idea,
and which a built-in tuple definitely wouldn't do. If you couldn't name its
fields, then any Tuple containing the
On 2012-09-24 22:45, Nick Sabalausky wrote:
Because 'b' is neither being assigned to an (int) nor passed into a
template/func parameter that's expecting an (int).
Either I'm just stupid or I've failed completely to understand implicit
convertible to.
Another example:
struct Foo
{
On 2012-09-25 00:28, bearophile wrote:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
What about:
||
|1|
|1, 2|
--
/Jacob Carlborg
On 2012-09-25 03:19, ixid wrote:
What would a special case where the first level of tuple (with higher
levels being tuples in tuples) didn't require parens break? This would
be a beautiful syntax:
auto a = 1, 2; // A tuple of two ints
int, string fun(double, double d) {
return cast(int)
On 24/09/12 17:19, Andrei Alexandrescu wrote:
On 9/24/12 4:17 AM, Don Clugston wrote:
Regarding the comma operator: I'd love to deprecate it, but even if we
don't, could we at least ensure that this kind of rubbish doesn't
compile:
void main()
{
int x;
x 0, x += 5;
}
At present, because
Le 24/09/2012 17:29, Andrei Alexandrescu a écrit :
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and
Le 25/09/2012 01:59, Andrej Mitrovic a écrit :
On 9/25/12, Steven Schveighofferschvei...@yahoo.com wrote:
However, this brings up another issue, what about porting C code? All of
a sudden c style casts are no loner errors, but are type tuples!
I think they're still errors:
int x =
Le 24/09/2012 17:24, Andrei Alexandrescu a écrit :
On 9/24/12 9:27 AM, Philippe Sigaud wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
seewebsitetocontac...@semitwist.com wrote:
That said, I'm not necessarily opposed to the strict separation if we
had a good candidate for built-in
Le 24/09/2012 17:55, Philippe Sigaud a écrit :
On Mon, Sep 24, 2012 at 5:24 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I think my main problem with this is that I'm perfectly happy with the
baseline, which has tuple( as the left delimiter and ) as the right
delimiter.
I
Le 25/09/2012 01:39, Andrei Alexandrescu a écrit :
On 9/24/12 6:28 PM, bearophile wrote:
Timon Gehr:
My bikeshed is colored one of these:
(:1,2)
(|1,2)
At that point you might as well just use
import std.typecons : q = tuple, Q = Tuple;
Q!(int, int) foo(){
return q(1, 2);
}
If built-in
Le 25/09/2012 03:19, ixid a écrit :
What would a special case where the first level of tuple (with higher
levels being tuples in tuples) didn't require parens break? This would
be a beautiful syntax:
auto a = 1, 2; // A tuple of two ints
int, string fun(double, double d) {
return cast(int)
Le 25/09/2012 09:11, Jacob Carlborg a écrit :
On 2012-09-25 00:28, bearophile wrote:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
What about:
||
|1|
|1, 2|
Yeah and why not þ1, 2þ or ŀ1, 2ŀ ?
maybe ↓1, 2↓ is better ?
or « 1, 2 » (this one at least is readable).
Le 24/09/2012 16:59, foobar a écrit :
I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to 1 elements? *This* I'm against
for practical as well as completeness reasons. Andrei already provided
one example, and another would be a proper unit type.
deadalnix:
The problem with tuple() isn't its syntax, but what you can or
can't do with the resulting tuple.
See my first posts in this thread :-)
On the other hand it's handy to have a compact syntax for
something you use often
(http://en.wikipedia.org/wiki/Zipf%27s_law ).
Bye,
On 2012-09-25 12:05, deadalnix wrote:
It can get pretty confusing with , separated declarations :
int a, b = 3;
I wouldn't complain if that became illegal.
--
/Jacob Carlborg
On 9/25/12 6:10 AM, deadalnix wrote:
Le 24/09/2012 16:59, foobar a écrit :
I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to 1 elements? *This* I'm against
for practical as well as completeness reasons. Andrei already provided
one example, and
Le 25/09/2012 13:42, Jacob Carlborg a écrit :
On 2012-09-25 12:05, deadalnix wrote:
It can get pretty confusing with , separated declarations :
int a, b = 3;
I wouldn't complain if that became illegal.
Nor me (it was already confusing and confusable with comma expressions),
but a hell
Le 25/09/2012 15:38, Andrei Alexandrescu a écrit :
On 9/25/12 6:10 AM, deadalnix wrote:
Le 24/09/2012 16:59, foobar a écrit :
I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to 1 elements? *This* I'm against
for practical as well as completeness
On 9/25/12 10:05 AM, deadalnix wrote:
OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.
And both behave differently than Caml or Haskell's tuples.
isn't the time for some unification ? Preferably on how tuples work in
other languages, except if limitations can
On 9/23/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Oh, I completely forgot to mention this little bug I've had due to the
comma operator a few weeks ago:
import std.stdio;
int getInt(string op)
{
if (op, a)
You've shown it's clearly incompatible with the current language
and would break lots of code. What would it break if assignment
required explicit tuple brackets?
(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be
filled in order by the multiple return values of foo()
int foo()
On 2012-09-25 15:08:25 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 9/25/12 10:05 AM, deadalnix wrote:
OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.
And both behave differently than Caml or Haskell's tuples.
isn't the time for some
On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
Although to make things less confusing, I think the built-in language
tuple should give up its name. It could become a sequence. Renaming
the built-in one would certainly be less trouble, as code doesn't refer
to it by its name, and
On 2012-09-25 16:38:31 +, Jonathan M Davis jmdavisp...@gmx.com said:
On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
Although to make things less confusing, I think the built-in language
tuple should give up its name. It could become a sequence. Renaming
the built-in one would
On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
On 2012-09-25 16:38:31 +, Jonathan M Davis jmdavisp...@gmx.com said:
On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
Although to make things less confusing, I think the built-in language
tuple should give up its
2012/9/26 Jonathan M Davis jmdavisp...@gmx.com:
On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
On 2012-09-25 16:38:31 +, Jonathan M Davis jmdavisp...@gmx.com said:
On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
Although to make things less confusing, I think
The built-in tuple is also quite useful when defining templates.
In essence, we have two kinds of tuples: the built-in language
tuple is the unpacked tuple while Phobos hosts the packed
one. They each have their own use case and they can coexist
peacefully. But the language itself needs to
T.expand naturally has the connotation unpacked to me,
Isn't T.unpack clearer? Does that clash with a different usage
for the term?
On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:
But, the two are often confused, by the word tuple. It has
introduced badly confusion in many discussions.
To make matters worse, it had often invoked incorrect suggestion that
merging the two into one.
My suggestion is very
On 9/25/12 3:39 PM, ixid wrote:
T.expand naturally has the connotation unpacked to me,
Isn't T.unpack clearer? Does that clash with a different usage for the
term?
Let's stay with .expand.
Andrei
Le 25/09/2012 17:51, ixid a écrit :
You've shown it's clearly incompatible with the current language and
would break lots of code. What would it break if assignment required
explicit tuple brackets?
(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be filled in
order by the multiple
I meant to reply to your post rather than Jacob's.
Le 25/09/2012 17:08, Andrei Alexandrescu a écrit :
On 9/25/12 10:05 AM, deadalnix wrote:
OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.
And both behave differently than Caml or Haskell's tuples.
isn't the time for some unification ? Preferably on how tuples
On Tue, 25 Sep 2012 12:07:33 +0200
deadalnix deadal...@gmail.com wrote:
Le 25/09/2012 09:11, Jacob Carlborg a écrit :
On 2012-09-25 00:28, bearophile wrote:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
What about:
||
|1|
|1, 2|
Yeah and why not þ1, 2þ or ŀ1, 2ŀ ?
maybe ↓1, 2↓
On 9/25/12 4:37 PM, deadalnix wrote:
Le 25/09/2012 17:08, Andrei Alexandrescu a écrit :
On 9/25/12 10:05 AM, deadalnix wrote:
OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.
And both behave differently than Caml or Haskell's tuples.
isn't the time for some
On 9/25/12 4:14 PM, Jonathan M Davis wrote:
On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:
But, the two are often confused, by the word tuple. It has
introduced badly confusion in many discussions.
To make matters worse, it had often invoked incorrect suggestion that
merging the
On Tuesday, September 25, 2012 22:39:37 ixid wrote:
I meant to reply to your post rather than Jacob's.
It would help if you actually quoted at least _some_ of the post that you're
replying to. I have _no_ idea what post you're replying to here. Many people
view this newsgroup without any
On Tuesday, 25 September 2012 at 10:04:46 UTC, deadalnix wrote:
Le 25/09/2012 03:19, ixid a écrit :
What would a special case where the first level of tuple (with
higher
levels being tuples in tuples) didn't require parens break?
This would
be a beautiful syntax:
auto a = 1, 2; // A tuple of
On 9/25/12 4:44 PM, Jonathan M Davis wrote:
On Tuesday, September 25, 2012 22:39:37 ixid wrote:
I meant to reply to your post rather than Jacob's.
It would help if you actually quoted at least _some_ of the post that you're
replying to. I have _no_ idea what post you're replying to here. Many
On 09/25/2012 11:01 PM, Andrei Alexandrescu wrote:
On 9/25/12 4:14 PM, Jonathan M Davis wrote:
On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:
But, the two are often confused, by the word tuple. It has
introduced badly confusion in many discussions.
To make matters worse, it had
On 09/25/2012 09:29 PM, kenji hara wrote:
2012/9/26 Jonathan M Davis jmdavisp...@gmx.com:
On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
On 2012-09-25 16:38:31 +, Jonathan M Davis jmdavisp...@gmx.com said:
On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
On 23/09/12 22:40, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I
On Sunday, 23 September 2012 at 21:51:35 UTC, Nick Sabalausky
wrote:
Ok, here's a crazy idea:
Do the reasons for explicit tuple-expansion necessarily apply to
zero- and one-element tuples? I'm not so sure. Suppose we
allowed
implicit expansion on those...
Now I know what you're thinking:
On 2012-09-24 07:01, Nick Sabalausky wrote:
I think one of us is missing something, and I'm not entirely sure
who.
As I explained (perhaps poorly), the zero- and one-element tuples *would
still be* tuples. They would just be implicitly convertible to
non-tuple form *if* needed, and vice versa.
On 2012-09-23 22:40, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
+1
--
/Jacob Carlborg
On 2012-09-24 00:11, bearophile wrote:
This is a complex topic, and in this post I am not able to discuss
everything that needs to be discussed. So I will discuss only part of
the story.
First: tuples are important enough. I think they should be built-in in a
modern language, but maybe having
On Mon, 24 Sep 2012 10:56:40 +0200
Jacob Carlborg d...@me.com wrote:
On 2012-09-24 07:01, Nick Sabalausky wrote:
I think one of us is missing something, and I'm not entirely sure
who.
As I explained (perhaps poorly), the zero- and one-element tuples
*would still be* tuples. They
On Mon, 24 Sep 2012 10:47:38 +0200
foobar f...@bar.com wrote:
Nope.
One of the ways in math to build the positive numbers based on
set theory is via singletons:
n := |tuple of empty tuples|
so 1 is defined as { {} } whereas 0 is simply {}. That does
not work with the above suggestion.
On Mon, 24 Sep 2012 06:20:55 -0400
Nick Sabalausky seewebsitetocontac...@semitwist.com wrote:
On Mon, 24 Sep 2012 10:47:38 +0200
foobar f...@bar.com wrote:
Nope.
One of the ways in math to build the positive numbers based on
set theory is via singletons:
n := |tuple of empty tuples|
On 2012-09-24 12:06, Nick Sabalausky wrote:
No, because there's nothing typed (int) involved there. But you could do
this:
int a = 3;
(int) b = a;
a = b;
But you said:
They would just be implicitly convertible
to non-tuple form *if* needed, and vice versa.
To me that sounds
On 09/24/2012 05:25 AM, Andrei Alexandrescu wrote:
On 9/23/12 9:31 PM, deadalnix wrote:
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
I believe it is currently left-to-right for D,
Le 24/09/2012 14:15, Jacob Carlborg a écrit :
On 2012-09-24 12:06, Nick Sabalausky wrote:
No, because there's nothing typed (int) involved there. But you could do
this:
int a = 3;
(int) b = a;
a = b;
But you said:
They would just be implicitly convertible
to non-tuple form *if* needed, and
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
seewebsitetocontac...@semitwist.com wrote:
That said, I'm not necessarily opposed to the strict separation if we
had a good candidate for built-in tuple literal syntax. But *if* the
best we have is parens (and maybe there *is* something
On 9/24/12 8:18 AM, Timon Gehr wrote:
On 09/24/2012 05:25 AM, Andrei Alexandrescu wrote:
On 9/23/12 9:31 PM, deadalnix wrote:
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
I believe
The analysis in there fails to construct a case even half
strong that deprecating the comma operator could significantly
help tuples.
That is because it does not base the discussion on the right
limitations of built-in tuples:
auto (a,b) = (1,3);
(auto a, string b) = (1, 3);
Agreed, this is
On Mon, 24 Sep 2012 01:01:29 -0400, Nick Sabalausky
seewebsitetocontac...@semitwist.com wrote:
On Sun, 23 Sep 2012 18:48:22 -0400
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Once a one-element tuple becomes equivalent to the actual item,
there's an explosion of trouble and
On Monday, 24 September 2012 at 10:05:18 UTC, Nick Sabalausky
wrote:
On Mon, 24 Sep 2012 10:56:40 +0200
Jacob Carlborg d...@me.com wrote:
On 2012-09-24 07:01, Nick Sabalausky wrote:
I think one of us is missing something, and I'm not entirely
sure
who.
As I explained (perhaps poorly),
On Monday, 24 September 2012 at 10:20:01 UTC, Nick Sabalausky
wrote:
On Mon, 24 Sep 2012 10:47:38 +0200
foobar f...@bar.com wrote:
Nope.
One of the ways in math to build the positive numbers based
on set theory is via singletons:
n := |tuple of empty tuples|
so 1 is defined as { {} } whereas
On 9/24/12 1:01 AM, Nick Sabalausky wrote:
On Sun, 23 Sep 2012 18:48:22 -0400
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote:
Once a one-element tuple becomes equivalent to the actual item,
there's an explosion of trouble and special cases in the language and
in code that uses it. For
On 9/24/12 4:17 AM, Don Clugston wrote:
Regarding the comma operator: I'd love to deprecate it, but even if we
don't, could we at least ensure that this kind of rubbish doesn't compile:
void main()
{
int x;
x 0, x += 5;
}
At present, because comma expressions are expressions, not statements,
On Monday, 24 September 2012 at 14:52:21 UTC, Steven
Schveighoffer wrote:
(int[]) x;
int a = x.length;
is a == 0 or 1?
I agree with Andrei, we need something different.
This is exactly the question I was going to ask ...
I don't profess to be even close to an expert on tuples, but I
On 9/24/12 9:27 AM, Philippe Sigaud wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
seewebsitetocontac...@semitwist.com wrote:
That said, I'm not necessarily opposed to the strict separation if we
had a good candidate for built-in tuple literal syntax. But *if* the
best we have is
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and exactly the syntax I was going to propose!
Assume
On 9/24/12 11:29 AM, Andrei Alexandrescu wrote:
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and
On Monday, September 24, 2012 16:00:06 David Piepgrass wrote:
There is also no consideration in the DIP of what I consider one
of D's most confusing features: pre-expanded tuples or in
other words, type tuples.
That's a completely separate issue. The DIP doesn't even introduce normal
tuples
On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer
wrote:
Without any research or investigation, what about using a different
set of
On Mon, 24 Sep 2012 11:47:09 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
I can say that I have *avoided* tuples as return values because I don't
want to type Tuple!(x, y) as the return type. But I haven't come across
that need very much. You can say yeah, but what about auto?
On Mon, Sep 24, 2012 at 5:24 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I think my main problem with this is that I'm perfectly happy with the
baseline, which has tuple( as the left delimiter and ) as the right
delimiter.
I found it a bit long compared to other languages in
If tuples are ever introduced, I hope parentheses will not be used.
I would prefer something like this:
tuple2,1,8
Caligo:
If tuples are ever introduced, I hope parentheses will not be
used.
I would prefer something like this:
tuple2,1,8
That both breaks code, doesn't improve the syntax, but makes it
worse.
Bye,
bearophile
On 9/24/12 11:47 AM, Steven Schveighoffer wrote:
On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer
wrote:
Without any research or
On Sunday, September 23, 2012 16:40:34 Andrei Alexandrescu wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
My #1 concern here is that for loops do _not_ ever change how they function
with regards to commas (which the DIP seems to do, but it also seems to imply
that we
On 2012-09-24 15:05, deadalnix wrote:
I understand your example, but in it, no (int) are involved. So no
conversion have to be done (and you get an error).
What has that to do with anything. Example:
auto a = 3;
There's no mention of int in that example, yet a is still an int.
You see in
On 2012-09-24 17:24, Andrei Alexandrescu wrote:
I think my main problem with this is that I'm perfectly happy with the
baseline, which has tuple( as the left delimiter and ) as the right
delimiter. I'd be more excited to invent notation if there was
overwhelming or at least considerable
1 - 100 of 165 matches
Mail list logo
