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 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
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
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: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 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 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) (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 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.
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
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 a
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
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 be
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
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
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
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 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 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
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
>> >>
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 re
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
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ŀ ?
>
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 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 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 o
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
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
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
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
http://ms
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
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,
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 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:
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
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 same
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
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 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 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 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, 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 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-
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
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 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 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 to
On 2012-09-28 19:09, deadalnix wrote:
It is ambiguous with the comma declaration syntax.
I could live without it.
--
/Jacob Carlborg
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 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 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
101 - 165 of 165 matches
Mail list logo
