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 e
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:
tuple<2,1,8>
Not using parentheses: a possibly valid idea!
Using angle brackets: never going to happen.
People HATE angle brackets. There is extreme
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 start
On 2012-09-28 19:09, deadalnix wrote:
It is ambiguous with the comma declaration syntax.
I could live without it.
--
/Jacob Carlborg
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 to
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
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
suggesti
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 com
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 Byz
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-
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 thou
On Wed, 26 Sep 2012 15:54:44 -0400, foobar 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
deconstruction.
Andre
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 it
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 wouldn'
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 std.typecons.Typ
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 c
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 same
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:
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 you
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.typeco
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") T
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,
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 suppos
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
http://ms
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
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 re
Le 25/09/2012 22:55, Nick Sabalausky a écrit :
On Tue, 25 Sep 2012 12:07:33 +0200
deadalnix 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
On 09/25/2012 09:29 PM, kenji hara wrote:
2012/9/26 Jonathan M Davis :
On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
On 2012-09-25 16:38:31 +, "Jonathan M Davis" said:
On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
Although to make things less confusing, I th
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 o
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 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 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 threa
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 un
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 t
On Tue, 25 Sep 2012 12:07:33 +0200
deadalnix 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ŀ ?
>
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 w
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 re
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
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
"T.expand" naturally has the connotation "unpacked" to me,
Isn't T.unpack clearer? Does that clash with a different usage
for the term?
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
2012/9/26 Jonathan M Davis :
> On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
>> On 2012-09-25 16:38:31 +, "Jonathan M Davis" said:
>> > On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
>> >> Although to make things less confusing, I think the built-in language
>> >>
On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
> On 2012-09-25 16:38:31 +, "Jonathan M Davis" 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 c
On 2012-09-25 16:38:31 +, "Jonathan M Davis" 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 certainly be le
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,
On 2012-09-25 15:08:25 +, Andrei Alexandrescu
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 unification ? Preferably on how
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 9/23/12, Andrei Alexandrescu 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")
return 1;
else
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 be
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
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 lo
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 a
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
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,
bearophil
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. e.
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) (d[0
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 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 24/09/2012 17:55, Philippe Sigaud a écrit :
On Mon, Sep 24, 2012 at 5:24 PM, 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 found it a bit long compared
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
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
bes
Le 25/09/2012 01:59, Andrej Mitrovic a écrit :
On 9/25/12, Steven Schveighoffer 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 = (int)foo;
Maybe the compile
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 e
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 comm
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) (d
On 2012-09-25 00:28, bearophile wrote:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
What about:
||
|1|
|1, 2|
--
/Jacob Carlborg
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
{
int
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) (d[0] * d[1]), "hello";
}
auto a,
On 9/25/12, Steven Schveighoffer 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 = (int)foo;
Maybe the compiler could figure out if a cast was attempted rath
On Mon, 24 Sep 2012 17:31:27 -0400, Nick Sabalausky
wrote:
On Mon, 24 Sep 2012 10:53:14 -0400
"Steven Schveighoffer" wrote:
(int[]) x;
int a = x.length;
is a == 0 or 1?
It'd be 1, but I agree that's a pretty solid counter-argument.
It would be if it were valid code :) d complains
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 tuples are not going to look like
(1, 2)
then imho
On 09/25/2012 12:28 AM, 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 tuples are not going to look like
(1, 2)
t
On Mon, 24 Sep 2012 21:50:34 +0200, Caligo wrote:
foo(<11,2,8>, a, b)
vs
foo((11,2,8), a, b)
Parentheses are everywhere in D. Sometimes it looks like Lisp.
And <> is ambiguous, ugly, an affront before Walter, and an abomination
born
in the fiery depths of hell. Can we please just leave i
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 tuples are not going to look like
(1, 2)
then imho we might as well leave them out,
On 09/24/2012 09:50 PM, Caligo wrote:
On Mon, Sep 24, 2012 at 11:37 AM, bearophile wrote:
That both breaks code, doesn't improve the syntax, but makes it worse.
Bye,
bearophile
foo(<11,2,8>, a, b)
vs
foo((11,2,8), a, b)
I don't spot a significant difference.
Parentheses are everywhere
On 09/24/2012 11:22 PM, Nick Sabalausky wrote:
On Mon, 24 Sep 2012 15:27:19 +0200
Philippe Sigaud wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
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
On Mon, 24 Sep 2012 12:51:18 -0400
Andrei Alexandrescu wrote:
> On 9/24/12 11:47 AM, Steven Schveighoffer wrote:
> > I just wanted to point out that it seems the largest trouble,
> > implementation-wise, for DIP19 is the choice of parentheses to
> > denote a tuple. If we do want to add built-in tu
On Mon, 24 Sep 2012 10:53:14 -0400
"Steven Schveighoffer" wrote:
>
> (int[]) x;
>
> int a = x.length;
>
> is a == 0 or 1?
>
It'd be 1, but I agree that's a pretty solid counter-argument.
On Mon, 24 Sep 2012 15:27:19 +0200
Philippe Sigaud wrote:
> On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
> 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
On Mon, 24 Sep 2012 16:50:47 +0200
"foobar" wrote:
> On Monday, 24 September 2012 at 10:05:18 UTC, Nick Sabalausky
> wrote:
> > On Mon, 24 Sep 2012 10:56:40 +0200
> > Jacob Carlborg wrote:
> >
> >> On 2012-09-24 07:01, Nick Sabalausky wrote:
> >>
> >> > I think one of us is missing something,
On Mon, 24 Sep 2012 21:16:06 +0200
Jacob Carlborg wrote:
> 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;
>
>
On Sunday, 23 September 2012 at 21:51:35 UTC, Nick Sabalausky
wrote:
*Logically* speaking, is there really any difference between a
one-element tuple and an ordinary single value? I don't think
so, and
here's why: What is a tuple, logically speaking? Multiple
values being
handled as if they we
foo(<11,2,8>, a, b)
vs
foo((11,2,8), a, b)
Parentheses are everywhere in D. Sometimes it looks like Lisp.
On Mon, Sep 24, 2012 at 11:37 AM, bearophile wrote:
>
> That both breaks code, doesn't improve the syntax, but makes it worse.
>
> Bye,
> bearophile
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 evid
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
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 mi
On 9/24/12 11:47 AM, Steven Schveighoffer wrote:
On Mon, 24 Sep 2012 11:29:53 -0400, 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 d
Caligo:
If tuples are ever introduced, I hope parentheses will not be
used.
I would prefer something like this:
tuple<2,1,8>
That both breaks code, doesn't improve the syntax, but makes it
worse.
Bye,
bearophile
If tuples are ever introduced, I hope parentheses will not be used.
I would prefer something like this:
tuple<2,1,8>
On Mon, Sep 24, 2012 at 5:24 PM, 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 found it a bit long compared to other languages in the beginning,
but I'v
On Mon, 24 Sep 2012 11:47:09 -0400, Steven Schveighoffer
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?" Cases
I'm refe
On Mon, 24 Sep 2012 11:29:53 -0400, 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,
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
tu
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 exac
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 y
On 9/24/12 9:27 AM, Philippe Sigaud wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
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 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
fe
On 9/24/12 1:01 AM, Nick Sabalausky wrote:
On Sun, 23 Sep 2012 18:48:22 -0400
Andrei Alexandrescu 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 example, divide and conquer c
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 10:20:01 UTC, Nick Sabalausky
wrote:
On Mon, 24 Sep 2012 10:47:38 +0200
"foobar" 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
1 - 100 of 165 matches
Mail list logo
