Heywood Floyd:
> First of all, I definitely think that how arrays are declared now would have
> to stay just the way it is,
> no matter what. I don't think stuff like that is changeable this late in a
> language.
Recently I have suggested to remove the syntax:
new int[20];
And allow only:
new in
Mafi Wrote:
>
> I don't really like it. Of course the order of indices feels better but
> it breaks the rule of reading types from right to left. It also
> introduces more parenthesis and a new keyword into types (amongst const,
> immutable and delegate etc). Consider:
>shared array[3](con
On 16 July 2010 20:11, Mafi wrote:
> Am 16.07.2010 11:12, schrieb Heywood Floyd:
>
> Lars T. Kyllingstad Wrote:
>>
>> I do agree that, if possible, the language should match how most people
>>> think. But in this case, it is impossible, because of templates. How
>>> would the following exampl
Am 16.07.2010 11:12, schrieb Heywood Floyd:
Lars T. Kyllingstad Wrote:
I do agree that, if possible, the language should match how most people
think. But in this case, it is impossible, because of templates. How
would the following example work with T = int[3], if arrays worked the
way you wa
On 16 July 2010 11:12, Heywood Floyd wrote:
> Lars T. Kyllingstad Wrote:
> (...)
>
> When we introduce templates, this should still work:
>
> struct MyArray(T){
> array[3] T a;
> }
>
> // Let's try
> T == array[11] int
>
> array[3] T a;
> array[3] (array[11] int) a;
> array[3] array[11] a;
> ar
Lars T. Kyllingstad Wrote:
> I do agree that, if possible, the language should match how most people
> think. But in this case, it is impossible, because of templates. How
> would the following example work with T = int[3], if arrays worked the
> way you want?
>
> struct MyArray(T)
> {
On Thursday 15 July 2010 22:20:17 bearophile wrote:
> Jonathan M Davis:
> > Personally, I'd advise you to just use dynamic arrays unless you do
> > some profiling and find that a static array is better in a particular
> > case.
>
> To program you need a less naive view. I sometimes start using dyn
Jonathan M Davis:
> Personally, I'd advise you to just use dynamic arrays unless you do
> some profiling and find that a static array is better in a particular case.
To program you need a less naive view. I sometimes start using dynamic arrays
everywhere because they are handy, then I profile cod
Jonathan M Davis:
> [5](int) const a;
Go language uses something similar, and I find it a bit better than D syntax.
Bye,
bearophile
On Wed, 14 Jul 2010 16:57:13 -0400, Heywood Floyd wrote:
> Lars T. Kyllingstad Wrote:
>
>
>> But then arrays would be different from all other types! If you have
>> an array of 3 Ts, that is written T[3], regardless of what T is. Now
>> consider these two cases:
>>
>>A. T is an int. Then
On Wednesday, July 14, 2010 13:57:13 Heywood Floyd wrote:
>
> Thank you for the elaborate answer!
>
> When you put it like that, it does make sense. But I'm sorry. I refuse. The
> reason I refuse is those examples are void of any higher semantic meaning.
> Once we add a semantic meaning, it simpl
Lars T. Kyllingstad Wrote:
>
> But then arrays would be different from all other types! If you have an
> array of 3 Ts, that is written T[3], regardless of what T is. Now
> consider these two cases:
>
>A. T is an int. Then T[3] becomes int[3].
>
>B. T is an int[string]. Then T[3]
On Mon, 12 Jul 2010 17:23:16 -0400, Heywood Floyd wrote:
> bearophile Wrote:
>
>> Heywood Floyd:
>> > This had me crazy. I ended up putting the brackets on the variable,
>> > like
>> > int marr[3][5];
>> > then it worked like
>> > marr[2][4] = 9;
>>
>> That's present only for compatibility w
Heywood Floyd:
> Aha, good to know! Thanks!
> (So this might go away in the future? Or require a -cstyle compile flag?)
It's just an idea of mine, my weight in D design is near zero, and Walter
doesn't love warnings. I don't know if C-style array definitions will ever go
away from D, don't hold
bearophile Wrote:
> Heywood Floyd:
> > This had me crazy. I ended up putting the brackets on the variable, like
> > int marr[3][5];
> > then it worked like
> > marr[2][4] = 9;
>
> That's present only for compatibility with C syntax, this means that you can
> use it to perform a quicker port
Heywood Floyd:
> This had me crazy. I ended up putting the brackets on the variable, like
> int marr[3][5];
> then it worked like
> marr[2][4] = 9;
That's present only for compatibility with C syntax, this means that you can
use it to perform a quicker port of C code to D, but you are suppose
This had me crazy. I ended up putting the brackets on the variable, like
int marr[3][5];
then it worked like
marr[2][4] = 9;
Hello dcoder,
Hello.
I'm wondering why in D if you declare a fixed multi dimensional array,
you have to reverse the index order to access an element.
When declaring an array, the base type is getting wrapped. When using an
array, the base types get unwrapped.
Because both forms place the [
dcoder wrote:
I'm wondering why in D if you declare a fixed multi dimensional array,
you
have to reverse the index order to access an element. I know it has
something
to do with how tightly [] bind, but the consequence is that it seems so
different to other languages, it makes it error pro
Hello.
I'm wondering why in D if you declare a fixed multi dimensional array, you
have to reverse the index order to access an element. I know it has something
to do with how tightly [] bind, but the consequence is that it seems so
different to other languages, it makes it error prone. So here's
20 matches
Mail list logo
