On 12/17/2013 07:21 PM, bearophile wrote:
But my suggested syntax is not that good, here $ has already a meaning,
that is the whole length of b, So some different idea is needed here :-(
b[0 .. $] = foo();
Sorry, I can't resist... Golden rule of system programming language
syntax: When in
Namespace:
Done:
https://github.com/D-Programming-Language/dmd/pull/2958
If you have a situation like this:
int[3] foo() {
typeof(return) a;
return a;
}
void main() {
int[100] b;
b[0 .. 3] = foo();
}
Can you use code like this to infer the length of the part needed
to
On Tuesday, 17 December 2013 at 17:01:55 UTC, bearophile wrote:
Namespace:
Done:
https://github.com/D-Programming-Language/dmd/pull/2958
If you have a situation like this:
int[3] foo() {
typeof(return) a;
return a;
}
void main() {
int[100] b;
b[0 .. 3] = foo();
}
Can you
Namespace:
No, not currently. But it is an interesting idea. Maybe I will
implement this.
A use case:
https://d.puremagic.com/issues/show_bug.cgi?id=11757#c3
Visible in this line:
key2[0 .. digestSize] = key.md5Of;
But my suggested syntax is not that good, here $ has already a
meaning,
On Friday, 13 December 2013 at 00:37:36 UTC, Namespace wrote:
Why don't you discuss on github?
And finally I did it:
auto[$] a_arr2 = dyn_arr[4 .. 8];
assert(is(typeof(a_arr2) == int[4]));
I will make a Pull Request tomorrow. Hope my code isn't that
bad. :/
Done:
I created a separate branch for the syntax Type[$] and auto[$]:
https://github.com/Dgame/dmd/commit/438a519d28d1683086083e673b2630a64c269f5f
Example:
int[$] arr_a1 = [54, 74, 90, 2010];
assert(is(typeof(arr_a1) == int[4]));
assert(arr_a1 == [54, 74, 90, 2010]);
int[$] arr_a2 = [2010, 90,
Namespace:
Sadly I don't know how I could deduce the type of:
auto[$] a_arr2 = dyn_arr[4 .. 8]; /// Sadly not possible for me
It seems a valid use case.
Bye,
bearophile
I presume the situation with this code is not changed by your
patches:
string[3] a = [redgreen,blue];
void main() {}
Bye,
bearophile
string[3] a = [redgreen,blue];
void main() {}
I suggested to support such incomplete literals only with this
extra syntax:
int[3] a = [1, 2, ...];
void main() {}
Bye,
bearophile
On 12/11/2013 05:09 PM, bearophile wrote:
Ali Çehreli:
int[] arr2 = [7, 8, 9]s;
assert(is(typeof(arr2) == int[3]));
That looks very confusing. The left-hand side looks like a slice,
which I can append elements to but its type is a static array?
No, the type of the literal is
Ali Çehreli:
But look at the assertion: the type of the *slice* arr2 is
int[3]. :)
I didn't notice that. It looks strange... I don't understand it.
Bye,
bearophile
On Thursday, 12 December 2013 at 15:35:52 UTC, bearophile wrote:
Ali Çehreli:
But look at the assertion: the type of the *slice* arr2 is
int[3]. :)
I didn't notice that. It looks strange... I don't understand it.
Bye,
bearophile
I already pointed out why it was that way AND that it's
Namespace:
Your gig:
https://github.com/D-Programming-Language/dmd/pull/2952#discussion_r8288045
This is part of the thread there:
Furhtermore, what if we indeed want to pass a dynamic array ?
Kenji Use cast. In real world, if overloaded function takes both
int[] and int[3], normally
Why don't you discuss on github?
And finally I did it:
auto[$] a_arr2 = dyn_arr[4 .. 8];
assert(is(typeof(a_arr2) == int[4]));
I will make a Pull Request tomorrow. Hope my code isn't that bad.
:/
On Thursday, 12 December 2013 at 18:20:25 UTC, bearophile wrote:
Namespace:
Your gig:
https://github.com/D-Programming-Language/dmd/pull/2952#discussion_r8288045
This is part of the thread there:
Furhtermore, what if we indeed want to pass a dynamic array
?
Kenji Use cast. In real world,
On Friday, 13 December 2013 at 04:13:04 UTC, Kenji Hara wrote:
On Thursday, 12 December 2013 at 18:20:25 UTC, bearophile wrote:
If I have a function foo that takes a slice as input, and I
want to pass it two arrays, the first time allocated on the
heap and the second on the stack, I have to
On Friday, December 13, 2013 07:19:50 Maxim Fomin wrote:
On Friday, 13 December 2013 at 04:13:04 UTC, Kenji Hara wrote:
On Thursday, 12 December 2013 at 18:20:25 UTC, bearophile wrote:
If I have a function foo that takes a slice as input, and I
want to pass it two arrays, the first time
On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli wrote:
On 12/10/2013 04:37 PM, Namespace wrote:
int[] arr2 = [7, 8, 9]s;
assert(is(typeof(arr2) == int[3]));
That looks very confusing. The left-hand side looks like a
slice, which I can append elements to but its type is
On Wednesday, 11 December 2013 at 09:49:13 UTC, Namespace wrote:
On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli
wrote:
On 12/10/2013 04:37 PM, Namespace wrote:
int[] arr2 = [7, 8, 9]s;
assert(is(typeof(arr2) == int[3]));
That looks very confusing. The left-hand side
On Wednesday, 11 December 2013 at 16:28:39 UTC, Chris Cain wrote:
On Wednesday, 11 December 2013 at 09:49:13 UTC, Namespace wrote:
On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli
wrote:
On 12/10/2013 04:37 PM, Namespace wrote:
int[] arr2 = [7, 8, 9]s;
On Wednesday, 11 December 2013 at 18:31:20 UTC, Namespace wrote:
On Wednesday, 11 December 2013 at 16:28:39 UTC, Chris Cain
wrote:
On Wednesday, 11 December 2013 at 09:49:13 UTC, Namespace
wrote:
On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli
wrote:
On 12/10/2013 04:37 PM,
Namespace:
void main() {
int[] arr0 = [1, 2, 3];
assert(is(typeof(arr0) == int[]));
assert(arr0 == [1, 2, 3]);
int[3] arr1 = [4, 5, 6]s;
assert(is(typeof(arr1) == int[3]));
assert(arr1 == [4, 5, 6]);
int[] arr2 = [7, 8, 9]s;
On Wednesday, 11 December 2013 at 19:51:24 UTC, bearophile wrote:
Namespace:
void main() {
int[] arr0 = [1, 2, 3];
assert(is(typeof(arr0) == int[]));
assert(arr0 == [1, 2, 3]);
int[3] arr1 = [4, 5, 6]s;
assert(is(typeof(arr1) == int[3]));
Namespace:
I'm unsure. I'm not that familiar with dmd at all, so maybe
some more advanced guy like Kenji should review my code and
create an own, better pull.
In that code there is both the [$] and the []s syntaxes. So it's
better to submit them as two separated pull requests for the D
Namespace:
I'm pretty nervous, but here is the first:
https://github.com/D-Programming-Language/dmd/pull/2952
Good. Keep in mind that at best it will take a month or more for
your patch to be accepted. Also patches that implement basic
language features like this pass a stringent process of
On Wednesday, 11 December 2013 at 23:20:30 UTC, bearophile wrote:
Namespace:
I'm pretty nervous, but here is the first:
https://github.com/D-Programming-Language/dmd/pull/2952
Good. Keep in mind that at best it will take a month or more
for your patch to be accepted. Also patches that
Ali Çehreli:
int[] arr2 = [7, 8, 9]s;
assert(is(typeof(arr2) == int[3]));
That looks very confusing. The left-hand side looks like a
slice, which I can append elements to but its type is a static
array?
No, the type of the literal is of a fixed-side array, but it gets
assigned
Namespace:
Your gig:
https://github.com/D-Programming-Language/dmd/pull/2952#discussion_r8288045
My enhancement request was for the array[$] syntax. The idea of
[]s was invented by someone else (Timothee Cour?).
I like the practical comments by Hara. If Kenji thinks the []s is
not useful
On Wed, Dec 11, 2013 at 5:17 PM, bearophile bearophileh...@lycos.comwrote:
Namespace:
Your gig: https://github.com/D-Programming-Language/dmd/pull/
2952#discussion_r8288045
My enhancement request was for the array[$] syntax. The idea of []s was
invented by someone else (Timothee Cour?).
Timothee Cour:
void fun(int[3]) {}
void main() {
int[3] x = [1, 2, 3];
fun(x); // OK
fun([1, 2, 3]); // error
fun([1, 2, 3]s); // OK
}
Sorry, there's no error there.
yes, that was the prime motivation for DIP34,
It seems Hara has received your message:
On Tuesday, 10 December 2013 at 07:46:25 UTC, Jonathan M Davis
wrote:
On Tuesday, December 10, 2013 08:29:02 Kenji Hara wrote:
On Tuesday, 10 December 2013 at 07:15:43 UTC, Jonathan M Davis
wrote:
On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
On 12/09/2013 10:52 PM, Jonathan M
On Tuesday, December 10, 2013 09:00:22 Namespace wrote:
I use this implict converting to static arrays very often and if
we deprecate it, we really need something to declare static array
literals.
Implicit conversion isn't the problem. It's the fact that there are two
possible matches, and it
On Tuesday, 10 December 2013 at 08:26:34 UTC, Jonathan M Davis
wrote:
On Tuesday, December 10, 2013 09:00:22 Namespace wrote:
I use this implict converting to static arrays very often and
if
we deprecate it, we really need something to declare static
array
literals.
Implicit conversion
On Tuesday, December 10, 2013 10:10:22 Namespace wrote:
Yeah I remember, but Kenji made a Pull Request to change this.
Regardless it would be very useful to have static array literals.
It should be possible to do that via a templated function which takes a static
array and then returns it.
On Tuesday, 10 December 2013 at 09:28:27 UTC, Jonathan M Davis
wrote:
On Tuesday, December 10, 2013 10:10:22 Namespace wrote:
Yeah I remember, but Kenji made a Pull Request to change this.
Regardless it would be very useful to have static array
literals.
It should be possible to do that via
On Tuesday, December 10, 2013 10:33:33 Namespace wrote:
On Tuesday, 10 December 2013 at 09:28:27 UTC, Jonathan M Davis
wrote:
On Tuesday, December 10, 2013 10:10:22 Namespace wrote:
Yeah I remember, but Kenji made a Pull Request to change this.
Regardless it would be very useful to have
On Tuesday, 10 December 2013 at 09:42:50 UTC, Jonathan M Davis
wrote:
On Tuesday, December 10, 2013 10:33:33 Namespace wrote:
On Tuesday, 10 December 2013 at 09:28:27 UTC, Jonathan M Davis
wrote:
On Tuesday, December 10, 2013 10:10:22 Namespace wrote:
Yeah I remember, but Kenji made a Pull
On Tuesday, 10 December 2013 at 09:28:27 UTC, Jonathan M Davis
wrote:
On Tuesday, December 10, 2013 10:10:22 Namespace wrote:
auto staticLiteral(T, size_t n)(T[n] literal)
{
return literal;
}
auto staticArray = staticLiteral([1, 2, 3, 4]);
Why do you think this is possible? If an array
On Tuesday, December 10, 2013 11:19:45 Kenji Hara wrote:
On Tuesday, 10 December 2013 at 09:28:27 UTC, Jonathan M Davis
wrote:
On Tuesday, December 10, 2013 10:10:22 Namespace wrote:
auto staticLiteral(T, size_t n)(T[n] literal)
{
return literal;
}
auto staticArray =
On 12/10/2013 08:29 AM, Kenji Hara wrote:
This is an intended behavior. An array literal has dynamic array type
*by default*.
But all of literals in D behave as polymorphic.
char c = 'A'; // character literal has char type by default
dchar d = 'A'; // but it may be implicitly typed as
On Tuesday, 10 December 2013 at 07:32:08 UTC, Marco Leise wrote:
[1,2,3] looks like a static array to me. And if overload
resolution picked the most specialized function it seems
natural to call the int[3] version.
My reasoning being that static arrays can be implicitly
converted to dynamic
Jonathan M Davis:
and while [1, 2, 3]s is nice and short, all it does
over staticLiteral([1, 2, 3]) is save some typing, and it
requires language changes,
[1, 2, 3]s seems nice.
On Tuesday, 10 December 2013 at 12:54:58 UTC, bearophile wrote:
Jonathan M Davis:
and while [1, 2, 3]s is nice and short, all it does
over staticLiteral([1, 2, 3]) is save some typing, and it
requires language changes,
[1, 2, 3]s seems nice.
What's with {1, 2, 3}? Should be easy to
Namespace:
What's with {1, 2, 3}? Should be easy to implement and it's
known from C/C++/Java/C#
In D {} has plenty of meanings already :-)
Bye,
bearophile
On Tuesday, 10 December 2013 at 07:29:03 UTC, Kenji Hara wrote:
This is an intended behavior. An array literal has dynamic
array type *by default*.
But all of literals in D behave as polymorphic.
One of good examples why weakly typed literals suck.
On Tuesday, 10 December 2013 at 14:20:51 UTC, bearophile wrote:
Namespace:
What's with {1, 2, 3}? Should be easy to implement and it's
known from C/C++/Java/C#
In D {} has plenty of meanings already :-)
Bye,
bearophile
That is no reason against it. ;)
On Tuesday, 10 December 2013 at 14:20:51 UTC, bearophile wrote:
Namespace:
What's with {1, 2, 3}? Should be easy to implement and it's
known from C/C++/Java/C#
In D {} has plenty of meanings already :-)
Bye,
bearophile
I've tried it in the last hour and as I thought, with a few
changes
Am Tue, 10 Dec 2013 00:26:22 -0800
schrieb Jonathan M Davis jmdavisp...@gmx.com:
On Tuesday, December 10, 2013 09:00:22 Namespace wrote:
I use this implict converting to static arrays very often and if
we deprecate it, we really need something to declare static array
literals.
Implicit
Am Tue, 10 Dec 2013 11:56:40 +0100
schrieb Kenji Hara k.hara...@gmail.com:
On Tuesday, 10 December 2013 at 07:32:08 UTC, Marco Leise wrote:
[1,2,3] looks like a static array to me. And if overload
resolution picked the most specialized function it seems
natural to call the int[3] version.
On Tuesday, 10 December 2013 at 14:20:51 UTC, bearophile wrote:
Namespace:
What's with {1, 2, 3}? Should be easy to implement and it's
known from C/C++/Java/C#
In D {} has plenty of meanings already :-)
Bye,
bearophile
You was right, it was terrible and so I tried [1, 2, 3]s as
syntax.
On Wednesday, 11 December 2013 at 00:37:24 UTC, Namespace wrote:
On Tuesday, 10 December 2013 at 14:20:51 UTC, bearophile wrote:
Namespace:
What's with {1, 2, 3}? Should be easy to implement and it's
known from C/C++/Java/C#
In D {} has plenty of meanings already :-)
Bye,
bearophile
You
On 12/10/2013 04:37 PM, Namespace wrote:
int[] arr2 = [7, 8, 9]s;
assert(is(typeof(arr2) == int[3]));
That looks very confusing. The left-hand side looks like a slice, which
I can append elements to but its type is a static array?
Ali
On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
I just found weird D behavior about inference of array types.
Let's suppose we have these overloaded functions:
import std.stdio;
void bar(const(int[3]) arr)
{
writeln(static array);
}
void bar(const(int[]) arr)
{
On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
I just found weird D behavior about inference of array types.
Let's suppose we have these overloaded functions:
import std.stdio;
void bar(const(int[3]) arr)
{
writeln(static array);
On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
I just found weird D behavior about inference of array types.
Let's suppose we have these overloaded functions:
import
On Tuesday, 10 December 2013 at 07:15:43 UTC, Jonathan M Davis
wrote:
On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
I just found weird D behavior about inference of array
Am Mon, 09 Dec 2013 23:15:27 -0800
schrieb Jonathan M Davis jmdavisp...@gmx.com:
On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
I just found weird D behavior about inference
On Tuesday, December 10, 2013 08:29:02 Kenji Hara wrote:
On Tuesday, 10 December 2013 at 07:15:43 UTC, Jonathan M Davis
wrote:
On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
Am Tue, 10 Dec 2013 08:29:02 +0100
schrieb Kenji Hara k.hara...@gmail.com:
This is an intended behavior. An array literal has dynamic array
type *by default*.
But all of literals in D behave as polymorphic.
char c = 'A'; // character literal has char type by default
dchar d = 'A'; //
59 matches
Mail list logo
