Re: Running unit tests from DUB single file packages

[drug via Digitalmars-d-learn]

On 12/22/20 8:32 PM, jmh530 wrote:

On Tuesday, 22 December 2020 at 15:06:09 UTC, drug wrote:

[snip]


But what do you mean exactly by "work with dependency"? As I 
understand, `dub test` does not run unit tests in dependencies and 
single file packages work with dependencies in general. Do you mean 
something else? I'm finishing the new PR to fix #2051 finally and I'd 
like to know if there is something else I should include in it.


https://github.com/dlang/dub/pull/2064


Thanks. It looks like your UT with taggedalgebraic does exactly what I 
was looking for.


My problem is that run.dlang.org will skip unittests when you have 
dependencies. I had made some progress on fixing this a few months ago 
[1], but put it on the back burner when I ran into similar issues that 
the OP was dealing with. The problem ultimately came down to dub test 
not working with --single, which it looks like this latest PR will fix 
for good.


[1] https://github.com/dlang-tour/core-exec/pull/56


Ah, I see. Then I would say that `dub test` doesn't run unit tests from 
the main source file (where the main function is placed). And this is 
the reason, I guess. Now `dub test` runs unit tests from the main source 
file if the package is a single file one. I think that dependencies is 
irrelevant here, at least I didn't do anything special for them. Let's 
see what happens.

Re: Why is (int[int] s = int[int].init) not allowed

[Daniel Kozak via Digitalmars-d-learn]

Dne st 23. 12. 2020 1:00 uživatel Steven Schveighoffer via
Digitalmars-d-learn  napsal:

> On 12/22/20 5:44 PM, Daniel Kozak wrote:
> > On Tue, Dec 22, 2020 at 10:15 PM Andre Pany via Digitalmars-d-learn
> >  > > wrote:
> >
> > Hi,
> >
> > I am really confused, why is this valid:
> > void sample(string[string] s = string[string].init){}
> >
> > while this causes syntax errors?
> >
> > void sample_invalid1(double[string] s = double[string].init){}
> > void sample_invalid2(int[int] s = int[int].init){}
> >
> > Kind regards
> > André
> >
> >
> > As has been said this is an oddity in the grammar. But why would anyone
> > need to use this anyway?
> >
> >void sample_invalid2(int[int] s = int[int].init){}
> >
> > seems really awful to me anyway.
>
> Yeah:
>
> void sample_valid(int[int] s = null)
>
> -Steve


Yes AA.init is null per doc.

https://dlang.org/spec/hash-map.html#construction_and_ref_semantic

Re: Slice allocation after appending

[Ali Çehreli via Digitalmars-d-learn]

On 12/22/20 2:12 PM, Rekel wrote:

> Now I'm unsure how to check this, I tried to a bit using the online
> editor and a bit of pointer usage which seemed to confirm my suspicion,
> but does this mean that taking a (small) slice at the end of a
> (possibly) very large dynamic array can lead to problematic behavior?

Considering D's "no stomp" behavior with array elements, yes, that can 
happen.


> Again I'm not very certain I fully understood how slices are
> implemented, but is this example, and the problem I imagine it leading
> to, valid?

It is valid. One can always copy the small array before appending to it 
and the large array would be preserved. (Uncomment the "ADD THIS" line 
below.)


I added a nested function to your code to help visualize the states of 
the two arrays:


import std.stdio;
import std.meta;

void main() {
  int[] a = new int[10]; // Imagine this is very large
  int[] b = a[$-1..$];   // Small slice at the end

  auto info(string tag) {
writefln!"\n(%s)"(tag);
writeln("array  ptrlengthcapacity");
writeln("");
static foreach (arr; AliasSeq!(a, b)) {
  writefln!"%-10s %s %8s %8s"(
arr.stringof, arr.ptr, arr.length, arr.capacity);
}
  }

  info("Before appending to b");
  // b = b.dup;// <-- ADD THIS
  b ~= 2;// b extends, possibly in place
  info("Before appending to a");
  a ~= -1;   // a no longer can, so the entire array needs
  info("At the end");
}

Try the -profile command line switch when compiling your program and it 
will show where memory allocations occur. Very helpful in exposing such 
problem spots...


Ali

Re: Can I output strings using core.stdc.stdio?

[Paul Backus via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 21:26:37 UTC, Godnyx wrote:

On Tuesday, 22 December 2020 at 21:10:59 UTC, Godnyx wrote:

Is there a way? If not then how std.stdio does it?


I should mention that I want to use it in a variable that can't 
be read at compile time so .toStringz is not working for me.


toStringz works just fine on variables that can't be read at 
compile time. You must be doing something else to trigger that 
error.

Re: Slice allocation after appending

[Basile B. via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 22:12:29 UTC, Rekel wrote:
According to the D slice article 
(https://dlang.org/articles/d-array-article.html), slices do 
not care where they start, only where they end, when checking 
whether expanding in place is permitable, or at least that is 
what I understood regarding it.


Now I'm unsure how to check this, I tried to a bit using the 
online editor and a bit of pointer usage which seemed to 
confirm my suspicion, but does this mean that taking a (small) 
slice at the end of a (possibly) very large dynamic array can 
lead to problematic behavior?


No there's some runtime and GC magic under the hood. Appending on 
the slice is more like a smart "copy on append" operation so "a" 
will always ends with -1 and "b" with 2. It's described here : 
https://dlang.org/articles/d-array-article.html#how-it-works

Re: Why is (int[int] s = int[int].init) not allowed

[Steven Schveighoffer via Digitalmars-d-learn]

On 12/22/20 5:44 PM, Daniel Kozak wrote:
On Tue, Dec 22, 2020 at 10:15 PM Andre Pany via Digitalmars-d-learn 
> wrote:


Hi,

I am really confused, why is this valid:
void sample(string[string] s = string[string].init){}

while this causes syntax errors?

void sample_invalid1(double[string] s = double[string].init){}
void sample_invalid2(int[int] s = int[int].init){}

Kind regards
André


As has been said this is an oddity in the grammar. But why would anyone 
need to use this anyway?


   void sample_invalid2(int[int] s = int[int].init){}

seems really awful to me anyway.


Yeah:

void sample_valid(int[int] s = null)

-Steve

Re: Getting started with graphqld

[aberba via Digitalmars-d-learn]

On Friday, 18 December 2020 at 03:36:05 UTC, Trustee wrote:

On Thursday, 17 December 2020 at 14:49:42 UTC, evilrat wrote:

On Tuesday, 15 December 2020 at 16:25:29 UTC, Trustee wrote:


connect a basic vibe-d app to a graphql backend.



umm, what?
Did you mean write graphql backend using vibe.d?


Vibe-d web app -> Vibe-d/GraphQL gateway server (a la Prisma 1) 
-> Vibe-d/GraphQL API server -> Data.


That's why I'm more interested in the workings of the package 
than a "How-To get a basic vibe-d/graphql server. I want to 
know which pieces are available OOTB to be put together to 
create the above, and which pieces need to be created.


Heres's a demo I put together 
https://github.com/aberba/graphqld-demo


A minimal example with only the essential APIs

Re: Trying to understand multidimensional arrays in D

[Ali Çehreli via Digitalmars-d-learn]

On 12/22/20 10:53 AM, Rekel wrote:> On Tuesday, 22 December 2020 at 
16:56:18 UTC, Ali Çehreli wrote:

>> >[4]Foo b; /* an array of four Foos */
>>
>> [4] already has a meaning. ;)
>
> It  does in that context? Do tell, I'm unaware.

An array literal with a single int element 4:

  pragma(msg, typeof([4]));

prints int[].

> Also, is it possible to move entire thread to a different forum group? 
> This feels more like a discussion fit for 'general'.

I've seen others "cross reference" to other threads perhaps by CC'ing 
the other newsgroup as well. (In case it's not obvious, these are 
newsgroups with a "forum" interface.)


Ali

Re: Why is (int[int] s = int[int].init) not allowed

[Daniel Kozak via Digitalmars-d-learn]

On Tue, Dec 22, 2020 at 10:15 PM Andre Pany via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> Hi,
>
> I am really confused, why is this valid:
> void sample(string[string] s = string[string].init){}
>
> while this causes syntax errors?
>
> void sample_invalid1(double[string] s = double[string].init){}
> void sample_invalid2(int[int] s = int[int].init){}
>
> Kind regards
> André
>

As has been said this is an oddity in the grammar. But why would anyone
need to use this anyway?

  void sample_invalid2(int[int] s = int[int].init){}

seems really awful to me anyway.

Slice allocation after appending

[Rekel via Digitalmars-d-learn]

According to the D slice article 
(https://dlang.org/articles/d-array-article.html), slices do not 
care where they start, only where they end, when checking whether 
expanding in place is permitable, or at least that is what I 
understood regarding it.


Now I'm unsure how to check this, I tried to a bit using the 
online editor and a bit of pointer usage which seemed to confirm 
my suspicion, but does this mean that taking a (small) slice at 
the end of a (possibly) very large dynamic array can lead to 
problematic behavior?

For example;


int[] a = new int[10]; // Imagine this is very large
int[] b = a[$-1..$];   // Small slice at the end
b ~= 2;// b extends, possibly in place
a ~= -1;   // a no longer can, so the entire array 
needs reallocating

(instead of be reallocating & a growing in place)

Again I'm not very certain I fully understood how slices are 
implemented, but is this example, and the problem I imagine it 
leading to, valid?

Re: Why is (int[int] s = int[int].init) not allowed

[Andre Pany via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 22:02:54 UTC, ag0aep6g wrote:

On Tuesday, 22 December 2020 at 21:11:12 UTC, Andre Pany wrote:

[...]


Looks like an oddity in the grammar.

`string` is an alias, meaning it's an identifier. And an 
identifier is a valid expression to the grammar. So 
`string[string]` is parsed as an IndexExpression. Only during 
semantic analysis does the compiler figure out that it's 
actually a type.


`double` and `int` aren't identifiers. They're keywords. And 
they're always types, never expressions. So `int[int]` cannot 
be parsed as an IndexExpression. It's parsed as a Type instead. 
And for a (grammatical) Type, there is no rule that allows 
`Type.Identifier`.


You can work around with parentheses:

(double[string]).init;
(int[int]).init


Thanks a lot!

Kind regards
Andre

Re: Why is (int[int] s = int[int].init) not allowed

[ag0aep6g via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 21:11:12 UTC, Andre Pany wrote:

I am really confused, why is this valid:
void sample(string[string] s = string[string].init){}

while this causes syntax errors?

void sample_invalid1(double[string] s = double[string].init){}
void sample_invalid2(int[int] s = int[int].init){}


Looks like an oddity in the grammar.

`string` is an alias, meaning it's an identifier. And an 
identifier is a valid expression to the grammar. So 
`string[string]` is parsed as an IndexExpression. Only during 
semantic analysis does the compiler figure out that it's actually 
a type.


`double` and `int` aren't identifiers. They're keywords. And 
they're always types, never expressions. So `int[int]` cannot be 
parsed as an IndexExpression. It's parsed as a Type instead. And 
for a (grammatical) Type, there is no rule that allows 
`Type.Identifier`.


You can work around with parentheses:

(double[string]).init;
(int[int]).init

Re: Can I output strings using core.stdc.stdio?

[Dave P. via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 21:37:23 UTC, Godnyx wrote:

On Tuesday, 22 December 2020 at 21:28:10 UTC, Dave P. wrote:

On Tuesday, 22 December 2020 at 21:10:59 UTC, Godnyx wrote:
[...]


Lol. Actually I just don't want to use Phobos and trying to 
stay on core. Unfortunately, my variable can't be read at 
compile time so I doesn't work. Any other ideas?


What I wrote should still work in non-betterC as long as you are 
linking to libc.


You can also just write to stdout directly if all you need is to 
write the string without any extra formatting:


fwrite(somestring.ptr, 1, somestring.length, stdout);

Re: Can I output strings using core.stdc.stdio?

[Godnyx via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 21:28:10 UTC, Dave P. wrote:

On Tuesday, 22 December 2020 at 21:10:59 UTC, Godnyx wrote:

Is there a way? If not then how std.stdio does it?


I assume you’re asking this because you don’t have access to 
std.stdio (such as using betterC).


The way to do it is to use the %.*s specifier in printf.

For example:

void print_string(string text){
printf(“%.*s\n”, cast(int)text.length, text.ptr);
}

The ‘.N' in front of the ’s’ says to not print more than N 
characters from the char*. using a ‘*’ says that the actual 
number of characters will be passed as an argument to printf 
instead of a hardcoded number. This is specified to be an int, 
so we have to cast the length of the string to int when calling 
printf. Finally, we need to pass the pointer to the actual 
character data, thus the text.ptr.


Lol. Actually I just don't want to use Phobos and trying to stay 
on core. Unfortunately, my variable can't be read at compile time 
so I doesn't work. Any other ideas?

Re: Can I output strings using core.stdc.stdio?

[Dave P. via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 21:10:59 UTC, Godnyx wrote:

Is there a way? If not then how std.stdio does it?


I assume you’re asking this because you don’t have access to 
std.stdio (such as using betterC).


The way to do it is to use the %.*s specifier in printf.

For example:

void print_string(string text){
printf(“%.*s\n”, cast(int)text.length, text.ptr);
}

The ‘.N' in front of the ’s’ says to not print more than N 
characters from the char*. using a ‘*’ says that the actual 
number of characters will be passed as an argument to printf 
instead of a hardcoded number. This is specified to be an int, so 
we have to cast the length of the string to int when calling 
printf. Finally, we need to pass the pointer to the actual 
character data, thus the text.ptr.

Re: Can I output strings using core.stdc.stdio?

[Godnyx via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 21:10:59 UTC, Godnyx wrote:

Is there a way? If not then how std.stdio does it?


I should mention that I want to use it in a variable that can't 
be read at compile time so .toStringz is not working for me.

Why is (int[int] s = int[int].init) not allowed

[Andre Pany via Digitalmars-d-learn]

Hi,

I am really confused, why is this valid:
void sample(string[string] s = string[string].init){}

while this causes syntax errors?

void sample_invalid1(double[string] s = double[string].init){}
void sample_invalid2(int[int] s = int[int].init){}

Kind regards
André

Can I output strings using core.stdc.stdio?

[Godnyx via Digitalmars-d-learn]

Is there a way? If not then how std.stdio does it?

Re: Trying to understand multidimensional arrays in D

[Rekel via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 16:55:40 UTC, Mike Parker wrote:

On Tuesday, 22 December 2020 at 15:31:06 UTC, Rekel wrote:



Don't take that as a defence of changing pointer syntax by the 
way, just noting I think the argument pointers and arrays 
should be defined using a similar syntax is not consistent 
when thinking about indexing & dereferencing.


Besides, I think '[4]foo* foos;' is quite clear.
"array of foo pointers" seems very natural to me.


Ugh. No thanks :-) My brain would short circuit every time I 
see it.


I take it you're not open to considering [4]*foo either?
I feel like there are quite strong argument for it, regarding 
readability & (definition vs operator) consistency.

Re: Trying to understand multidimensional arrays in D

[Rekel via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 16:56:18 UTC, Ali Çehreli wrote:

>[4]Foo b; /* an array of four Foos */

[4] already has a meaning. ;)


It  does in that context? Do tell, I'm unaware.

Also, is it possible to move entire thread to a different forum 
group? 

This feels more like a discussion fit for 'general'.

Re: Floating point values in structs.

[Dave P. via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 18:10:22 UTC, Dukc wrote:

On Friday, 18 December 2020 at 16:18:12 UTC, Dave P. wrote:

[...]


Honestly, I just want all bits zero. I don’t work with any 
platforms where null is not 0 and all-zero-bits aggregates can be 
efficiently represented in static storage. I don’t want the 
compiler inserting a ton of stores of nan to my float members. If 
I wanted something other than all bits zero for unmentioned 
members I would write constructors instead of using the struct 
initializer syntax. I generally design my data types such that 
all bits zero is a fully valid struct.


But it is what it is. I just have to remember to write `=0` 
whenever I have a float member or a char member.

Re: Floating point values in structs.

[Dukc via Digitalmars-d-learn]

On Friday, 18 December 2020 at 16:18:12 UTC, Dave P. wrote:
If the compiler is going to introduce the overhead of 
initializing all the variables anyway, why set it to nan when 
integer types get set to the useful default of 0?


Consider default value of `int*`. It is `null`, not a pointer to 
a newly-allocated 0. Most would probably agree that `null` works 
better, because it stands for "empty". 0 may or may not, 
depending on context.


It's this philosophy with floating-point values also. `0.0` might 
seem like a value when no value is intended, with `nan` there are 
no ambiguities.


More about this:
https://digitalmars.com/articles/b81.html
https://dlang.org/blog/2018/10/17/interfacing-d-with-c-arrays-part-1/

Re: Trying to understand multidimensional arrays in D

[ag0aep6g via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 16:56:18 UTC, Ali Çehreli wrote:

On 12/22/20 6:35 AM, ag0aep6g wrote:

> Flip the pointer syntax, too:
>
>  *Foo a; /* a pointer to a Foo */

I am not a language expert but I think that would make D's 
parsing complicated (like C++'s < token) because * already 
means "derefence" in that position. So, the parser would see 
*Foo as a potential compilation error but would have to parse 
forward, etc.


I'm not seriously suggesting changing D's syntax. The current 
syntax is fine with me.


`Foo* a;` is already "complicated", though. `*` can also mean 
multiplication in that position:



struct F
{
F opBinary(string op : "*")(F a) { return F(); }
void opBinary(string op : "+")(int a) { import std.stdio; 
writeln("Hello, world!"); }

}
void main()
{
F Foo;
F a;
Foo* a + 1; /* prints "Hello, world!" */
}


That's a convoluted example, of course. But it shows that the 
compiler already has to look ahead to decide what the `*` means. 
It doesn't just go "That's a type!" when it sees "Foo*".

Re: Running unit tests from DUB single file packages

[jmh530 via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 15:06:09 UTC, drug wrote:

[snip]


But what do you mean exactly by "work with dependency"? As I 
understand, `dub test` does not run unit tests in dependencies 
and single file packages work with dependencies in general. Do 
you mean something else? I'm finishing the new PR to fix #2051 
finally and I'd like to know if there is something else I 
should include in it.


https://github.com/dlang/dub/pull/2064


Thanks. It looks like your UT with taggedalgebraic does exactly 
what I was looking for.


My problem is that run.dlang.org will skip unittests when you 
have dependencies. I had made some progress on fixing this a few 
months ago [1], but put it on the back burner when I ran into 
similar issues that the OP was dealing with. The problem 
ultimately came down to dub test not working with --single, which 
it looks like this latest PR will fix for good.


[1] https://github.com/dlang-tour/core-exec/pull/56

Re: Trying to understand multidimensional arrays in D

[Ali Çehreli via Digitalmars-d-learn]

On 12/22/20 8:56 AM, Ali Çehreli wrote:

> * already means "derefence"

"dereference"

>  > But now we're no longer C-like, I guess.x

That x seems to be due to my fat Emacs fingers.

Ali

Re: Trying to understand multidimensional arrays in D

[Ali Çehreli via Digitalmars-d-learn]

On 12/22/20 6:35 AM, ag0aep6g wrote:

> Flip the pointer syntax, too:
>
>  *Foo a; /* a pointer to a Foo */

I am not a language expert but I think that would make D's parsing 
complicated (like C++'s < token) because * already means "derefence" in 
that position. So, the parser would see *Foo as a potential compilation 
error but would have to parse forward, etc.


>[4]Foo b; /* an array of four Foos */

[4] already has a meaning. ;)

> [][4]Foo c; /* a dynamic array of arrays of four Foos each */

I've just learned that the type of [] is void[]. Huh...

> But now we're no longer C-like, I guess.x

Ali

Re: Trying to understand multidimensional arrays in D

[Mike Parker via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 15:31:06 UTC, Rekel wrote:



Don't take that as a defence of changing pointer syntax by the 
way, just noting I think the argument pointers and arrays 
should be defined using a similar syntax is not consistent when 
thinking about indexing & dereferencing.


Besides, I think '[4]foo* foos;' is quite clear.
"array of foo pointers" seems very natural to me.


Ugh. No thanks :-) My brain would short circuit every time I see 
it.

Re: Trying to understand multidimensional arrays in D

[Rekel via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 15:24:04 UTC, Rekel wrote:
The way C syntax handles pointers isn't very consistent to 
begin with imo.
It's strange & and * are prepended to pointer variables for 
example, while indexing is postpended. Leads to stuff like;

(*array_of_pointers_to_arrays[2])[1]

vs

array_of_pointers_to_arrays[2]*[1]


and


(*array_of_pointers[1]).x'

vs

'array_of_pointers[1]*.x'


Don't take that as a defence of changing pointer syntax by the 
way, just noting I think the argument pointers and arrays should 
be defined using a similar syntax is not consistent when thinking 
about indexing & dereferencing.


Besides, I think '[4]foo* foos;' is quite clear.
"array of foo pointers" seems very natural to me.

Re: Trying to understand multidimensional arrays in D

[Rekel via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 14:15:12 UTC, Mike Parker wrote:
[][4]Foo is completely backwards from and inconsistent with the 
pointer declaration syntax. We shouldn't want to intentionally 
introduce inconsistencies.


The way C syntax handles pointers isn't very consistent to begin 
with imo.
It's strange & and * are prepended to pointer variables for 
example, while indexing is postpended. Leads to stuff like;

(*array_of_pointers_to_arrays[2])[1]

vs

array_of_pointers_to_arrays[2]*[1]


and


(*array_of_pointers[1]).x'

vs

'array_of_pointers[1]*.x'


On Tuesday, 22 December 2020 at 14:35:30 UTC, ag0aep6g wrote:

But now we're no longer C-like, I guess.


I think it'd still be quite C-like, same concepts samilar usage.
You're not using 'int foo[]' syntax anymore anyhow.

Re: Running unit tests from DUB single file packages

[drug via Digitalmars-d-learn]

On 12/22/20 10:52 AM, drug wrote:

On 12/21/20 7:31 PM, jmh530 wrote:

On Monday, 21 December 2020 at 11:31:49 UTC, drug wrote:

[snip]
Unfortunately I'm very busy. But I check it again and it turns out 
that the fix does not resolve the problem completely. This PR just 
remove the single file from testing so currently dub does not run 
unit tests in the single file package at all. The first variant 
(https://github.com/dlang/dub/pull/2050) fixes the issue indeed. I 
need to reevaluate these PRs and close the issue. I'll do it later.


Thanks for taking a look.


Not at all.

But what do you mean exactly by "work with dependency"? As I understand, 
`dub test` does not run unit tests in dependencies and single file 
packages work with dependencies in general. Do you mean something else? 
I'm finishing the new PR to fix #2051 finally and I'd like to know if 
there is something else I should include in it.


https://github.com/dlang/dub/pull/2064

Re: Trying to understand multidimensional arrays in D

[ag0aep6g via Digitalmars-d-learn]

On 22.12.20 15:15, Mike Parker wrote:

On Tuesday, 22 December 2020 at 13:59:54 UTC, Rekel wrote:



I am curious by the way, what do you think of the [][4]Row suggestion 
I gave? In a way you'd have your  & could eat it too, i think ^^

(Still a strange saying to me)


Currently, D's variable declaration syntax is consistent and, IMO, make 
sense:


Type Name | Extra Tokens | SymbolName
Foo   *   a;
Foo   [4] b;
(Foo  [4])[]  c;

[][4]Foo is completely backwards from and inconsistent with the pointer 
declaration syntax. We shouldn't want to intentionally introduce 
inconsistencies.


Flip the pointer syntax, too:

*Foo a; /* a pointer to a Foo */
  [4]Foo b; /* an array of four Foos */
[][4]Foo c; /* a dynamic array of arrays of four Foos each */

But now we're no longer C-like, I guess.

Re: Trying to understand multidimensional arrays in D

[Mike Parker via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 13:59:54 UTC, Rekel wrote:



I am curious by the way, what do you think of the [][4]Row 
suggestion I gave? In a way you'd have your  & could eat it 
too, i think ^^

(Still a strange saying to me)


Currently, D's variable declaration syntax is consistent and, 
IMO, make sense:


Type Name | Extra Tokens | SymbolName
Foo   *   a;
Foo   [4] b;
(Foo  [4])[]  c;

[][4]Foo is completely backwards from and inconsistent with the 
pointer declaration syntax. We shouldn't want to intentionally 
introduce inconsistencies.

Re: Trying to understand multidimensional arrays in D

[Rekel via Digitalmars-d-learn]

On Tuesday, 22 December 2020 at 07:19:49 UTC, Ali Çehreli wrote:

Let me try the history example:

  Row[4][] history;

Row array (of 4) array.



Fully disagreed: D's array syntax makes me happy; designed 
right. :)


I think i see your point, strange how a change of words makes 
some things make more sense. I'll do my best to think of it like 
that, even if i find it intuïtive. 


I am curious by the way, what do you think of the [][4]Row 
suggestion I gave? In a way you'd have your  & could eat it too, 
i think ^^

(Still a strange saying to me)