[]).stringof); // float[]
Or you can also pass a pointer to the first item of the fixed-size array:
bar(foo.ptr);
This change (static arrays becoming value types) will make D less similar to C,
so porting C code to D will be less easy (because if in the original C code an
array is passed, now
Tue, 20 Oct 2009 16:25:05 -0400, Robert Jacques thusly wrote:
On Tue, 20 Oct 2009 15:19:15 -0400, language_fan f...@bar.com.invalid
wrote:
Real tuple types do not have a special type tag which gets injected
implicitly with structs. So every time you try to do something
lightweight by
Yigal Chripun, el 21 de octubre a las 07:18 me escribiste:
On 21/10/2009 05:48, Robert Jacques wrote:
On Tue, 20 Oct 2009 23:30:48 -0400, Leandro Lucarella llu...@gmail.com
wrote:
Robert Jacques, el 20 de octubre a las 21:06 me escribiste:
Now, if SOL allowed tuples to do things you can't do
On Wed, 21 Oct 2009 02:23:09 -0400, language_fan f...@bar.com.invalid
wrote:
Tue, 20 Oct 2009 16:25:05 -0400, Robert Jacques thusly wrote:
On Tue, 20 Oct 2009 15:19:15 -0400, language_fan f...@bar.com.invalid
wrote:
Real tuple types do not have a special type tag which gets injected
Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote:
On Wed, 21 Oct 2009 02:23:09 -0400, language_fan f...@bar.com.invalid
wrote:
Tue, 20 Oct 2009 16:25:05 -0400, Robert Jacques thusly wrote:
On Tue, 20 Oct 2009 15:19:15 -0400, language_fan f...@bar.com.invalid
wrote:
Real tuple
language_fan wrote:
Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote:
My issue was that all your example _showed_ was nominal typing. Though I
didn't mention it by name, I did mention that if SOL tuples had
structural typing, it might would be a different story. (Well, until/if
On Wed, Oct 21, 2009 at 8:48 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
language_fan wrote:
Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote:
My issue was that all your example _showed_ was nominal typing. Though I
didn't mention it by name, I did mention that
Bill Baxter wrote:
Well, auto-flattening is a colossally bad idea to be sure.
Well that I agree with. I wonder if we need to fix it for D2. If we
don't, we risk to live with it like with a chronic cough.
Andrei
Wed, 21 Oct 2009 10:48:34 -0500, Andrei Alexandrescu thusly wrote:
language_fan wrote:
Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote:
My issue was that all your example _showed_ was nominal typing. Though
I didn't mention it by name, I did mention that if SOL tuples had
Wed, 21 Oct 2009 16:54:22 +, language_fan thusly wrote:
Wed, 21 Oct 2009 10:48:34 -0500, Andrei Alexandrescu thusly wrote:
language_fan wrote:
Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote:
My issue was that all your example _showed_ was nominal typing.
Though I didn't
language_fan wrote:
Wed, 21 Oct 2009 10:48:34 -0500, Andrei Alexandrescu thusly wrote:
language_fan wrote:
Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote:
My issue was that all your example _showed_ was nominal typing. Though
I didn't mention it by name, I did mention that if
Wed, 21 Oct 2009 16:54:22 +, language_fan thusly wrote:
Wed, 21 Oct 2009 10:48:34 -0500, Andrei Alexandrescu thusly wrote:
language_fan wrote:
Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote:
My issue was that all your example _showed_ was nominal typing.
Though I didn't
Wed, 21 Oct 2009 12:35:35 -0500, Andrei Alexandrescu thusly wrote:
language_fan wrote:
void main() {
Tuple!(int,int) a; // typeof(this) *is* the official tuple type
STuple!(int,int) b; // this is actually a struct
a = Tuple!(1,1); // ok
That doesn't work for me at all (with
language_fan, el 21 de octubre a las 17:52 me escribiste:
Wed, 21 Oct 2009 16:54:22 +, language_fan thusly wrote:
Wed, 21 Oct 2009 10:48:34 -0500, Andrei Alexandrescu thusly wrote:
language_fan wrote:
Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote:
My issue was that
language_fan wrote:
Wed, 21 Oct 2009 12:35:35 -0500, Andrei Alexandrescu thusly wrote:
language_fan wrote:
void main() {
Tuple!(int,int) a; // typeof(this) *is* the official tuple type
STuple!(int,int) b; // this is actually a struct
a = Tuple!(1,1); // ok
That doesn't work for me
Leandro Lucarella:
In python you can even do:
def f(a, b, c):
print a, b, c
x = (b, c)
f(a, *x) # calls to f(a, b, c)
In Python2.x you can also do:
def foo(x, (y, (z1, z2))):
print z2
print z1
print y
print x
Z = (1, 2)
yz = [0, Z]
foo(-1, yz)
That outputs:
2
1
Wed, 21 Oct 2009 13:41:50 -0500, Andrei Alexandrescu thusly wrote:
I don't understand what you are trying to accomplish. As far as I can
tell you want to do this:
Tuple!(int, int) a;
a = tuple(12, 13);
int x = a.field[0];
Not only that, but also this:
int d,e;
Tuple!(d,e) =
On Wed, 21 Oct 2009 22:41:50 +0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
language_fan wrote:
Wed, 21 Oct 2009 12:35:35 -0500, Andrei Alexandrescu thusly wrote:
language_fan wrote:
void main() {
Tuple!(int,int) a; // typeof(this) *is* the official tuple type
Denis Koroskin wrote:
On Wed, 21 Oct 2009 22:41:50 +0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
language_fan wrote:
Wed, 21 Oct 2009 12:35:35 -0500, Andrei Alexandrescu thusly wrote:
language_fan wrote:
void main() {
Tuple!(int,int) a; // typeof(this) *is* the
grauzone, el 21 de octubre a las 22:12 me escribiste:
Or even:
a, b = foo();
or
a, _ = foo();
Works in Python (tm)
_ is a regular symbol (variable name in this case), there is nothing
special about the second form, which is exactly the same as the first. And
BTW, the trailing ; is
language_fan wrote:
You somehow refuse to see that D has a tuple type which the compiler
calls a tuple.
D has tuples, it doesn't have tuple literals. Tuple attempts to supplant
that.
Andrei
Leandro Lucarella wrote:
grauzone, el 21 de octubre a las 22:12 me escribiste:
Or even:
a, b = foo();
or
a, _ = foo();
Works in Python (tm)
_ is a regular symbol (variable name in this case), there is nothing
special about the second form, which is exactly the same as the first. And
I
grauzone, el 21 de octubre a las 23:32 me escribiste:
Leandro Lucarella wrote:
grauzone, el 21 de octubre a las 22:12 me escribiste:
Or even:
a, b = foo();
or
a, _ = foo();
Works in Python (tm)
_ is a regular symbol (variable name in this case), there is nothing
special about
Walter Bright:
The previous behavior for function parameters can be retained by making
it a ref parameter:
void foo(ref T[3] a)
If I have generic code, like a templated function, that accepts both a dynamic
and a static array, the function call will change its performance signature
Walter Bright wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
able to return static arrays, and out parameters not being possible to
Walter Bright wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
able to return static arrays, and out parameters not being possible to
Jason House Wrote:
I've never heard the argument why they should be value types.
Weren't they value types from the start? That's surprise. What do you think is
memory layout of such array: int[3][] ? And what is memory layout of int[] ?
Walter Bright Wrote:
Andrei and I agonized over this for some time, and eventually came to
the conclusion that static arrays should become value types.
Nothing to agonize about really (except for C compatibility), they're value
types and their behavior must be consistent.
Don:
I think this change is mandatory. We need it for SIMD operations.
Why? Why the compiler can't optimize things and perform SIMD operations with
the fixed-sized array semantics of D1? (I ask this for LDC too, that's mostly
D1 still).
Bye,
bearophile
bearophile wrote:
Don:
I think this change is mandatory. We need it for SIMD operations.
Why? Why the compiler can't optimize things and perform SIMD operations with
the fixed-sized array semantics of D1? (I ask this for LDC too, that's mostly
D1 still).
Bye,
bearophile
Because they are
On Mon, 19 Oct 2009 18:50:46 -0700, Walter Bright
newshou...@digitalmars.com wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
able to
== Quote from bearophile (bearophileh...@lycos.com)'s article
Walter Bright:
The previous behavior for function parameters can be retained by making
it a ref parameter:
void foo(ref T[3] a)
If I have generic code, like a templated function, that accepts both a dynamic
and a static
dsimcha, el 20 de octubre a las 02:44 me escribiste:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language
Tue, 20 Oct 2009 10:34:35 -0300, Leandro Lucarella thusly wrote:
dsimcha, el 20 de octubre a las 02:44 me escribiste:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a
language_fan, el 20 de octubre a las 13:52 me escribiste:
Tue, 20 Oct 2009 10:34:35 -0300, Leandro Lucarella thusly wrote:
dsimcha, el 20 de octubre a las 02:44 me escribiste:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Currently, static arrays are (as in C)
On Mon, 19 Oct 2009 21:50:46 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Mon, 19 Oct 2009 21:50:46 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
Tue, 20 Oct 2009 12:39:47 -0300, Leandro Lucarella thusly wrote:
language_fan, el 20 de octubre a las 13:52 me escribiste:
Tue, 20 Oct 2009 10:34:35 -0300, Leandro Lucarella thusly wrote:
dsimcha, el 20 de octubre a las 02:44 me escribiste:
== Quote from Walter Bright
language_fan, el 20 de octubre a las 19:19 me escribiste:
One nasty thing about D's structs is that they don't have structural
equivalence relation unlike tuples. So you need to use the same
container struct type to get the same semantics. To achieve that you
would need some kind of STuple
On Tue, 20 Oct 2009 20:38:33 -0400, Leandro Lucarella llu...@gmail.com
wrote:
language_fan, el 20 de octubre a las 19:19 me escribiste:
One nasty thing about D's structs is that they don't have structural
equivalence relation unlike tuples. So you need to use the same
container struct type
Robert Jacques, el 20 de octubre a las 21:06 me escribiste:
Real tuple types do not have a special type tag which gets injected
implicitly with structs. So every time you try to do something
lightweight by emulating tuples, you need to refer to the global Tuple
type or bang your head to the
On Tue, 20 Oct 2009 22:45:53 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Tue, 20 Oct 2009 20:38:33 -0400, Leandro Lucarella
llu...@gmail.com wrote:
Yes, D support for tuples is way far from ideal.
How so? I think this is merely the difference
On Tue, 20 Oct 2009 23:30:48 -0400, Leandro Lucarella llu...@gmail.com
wrote:
Robert Jacques, el 20 de octubre a las 21:06 me escribiste:
Now, if SOL allowed tuples to do things you can't do today in D,
like assign a tuple to a struct with the same signature, then this
might be a point. But
On 21/10/2009 05:48, Robert Jacques wrote:
On Tue, 20 Oct 2009 23:30:48 -0400, Leandro Lucarella llu...@gmail.com
wrote:
Robert Jacques, el 20 de octubre a las 21:06 me escribiste:
Now, if SOL allowed tuples to do things you can't do today in D,
like assign a tuple to a struct with the same
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
able to return static arrays, and out parameters not being possible to
be static arrays.
Walter Bright Wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
able to return static arrays, and out parameters not being possible
On Mon, 19 Oct 2009 21:50:46 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
able
Jason House wrote:
Walter Bright Wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
able to return static arrays, and out parameters
Walter Bright wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
able to return static arrays, and out parameters not being possible to
Robert Jacques wrote:
Thank you. Will the various operators be overloaded? i.e. a = b + c;
instead of a[] = b[] + c[]; ?
Don't know. For now, I'd just leave the a=b+c syntax illegal. We can
always loosen things up later.
Saaa wrote:
Would that be D1D2 or only D2?
D2 only, as it changes the behavior.
On 20/10/2009 03:50, Walter Bright wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
able to return static arrays, and out parameters not
52 matches
Mail list logo
