November 21, 2016
On Monday, 21 November 2016 at 12:42:34 UTC, ZombineDev wrote:
> That was a proposal for D that was rejected in the last moment by Andrei. My guess is that ketmar's modified dmd has that feature implemented.

exactly. it is handy feature, so i used to it. and it slept into code (i usually test my code with rdmd before posting, but this time i forgot to specify --vanilla flag ;-).
November 21, 2016
On Monday, 21 November 2016 at 12:44:47 UTC, Jonathan M Davis wrote:
> Someone could create a DIP for it though and argue for it. If they did that convincingly enough, maybe it would become a feature. I suspect that the response will be though that since it's easy enough to just create a template to do the same thing, it's not worth adding to the language.
>
> - Jonathan M Davis

That's definitely what Walter would say. But I think it shouldn't be the only argument to not add a feature to the language itself: if some pattern is useful/frequent, and users implement it themselves every time, it should be either implemented in the compiler or in the standard library.

Besides that, it just seems inconsistent that D lacks this particular feature: fixed-sized arrays are there, type deduction is there, so where's type deduction for fixed-sized arrays? Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me:

int[_] array = [ 1, 2, 3 ];
November 22, 2016
On Monday, 21 November 2016 at 23:49:27 UTC, burjui wrote:
> Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me:
>
> int[_] array = [ 1, 2, 3 ];

alas, `_` is valid identifier, so `enum _ = 42; int[_] a;` is perfectly valid. dollar is simply most logical non-identifier character.
November 22, 2016
On Monday, 21 November 2016 at 12:44:47 UTC, Jonathan M Davis wrote:
> (it might have even had a PR which was rejected), and presumably, Ketmar added it to his own compiler, because he liked the feature.
exactly. it is the old patch from Kenji. the patch even survived C++ -> D transition, 'cause i love it so much. ;-)
November 22, 2016
Dne 21.11.2016 v 13:44 Jonathan M Davis via Digitalmars-d-learn napsal(a):

> ... it's easy enough to just create a
> template to do the same thing, it's not worth adding to the language.
That's a problem. I belive there is a lot of things which are easy to add by some kind of magic (template or mixins or some combination). But until this is add to standard library and doc, there is no way for other people to know about it. Even when there is a way (in standard library) it is not helpful.

Many people (like me) will start learning language from specs. So if there see something like:
int[$] x = [1, 2, 3]; // make static array, this make sense
but  x = [1, 2, 3]; // make dynamic array ,does not make sense
November 23, 2016
On Tuesday, 22 November 2016 at 00:08:05 UTC, ketmar wrote:
> On Monday, 21 November 2016 at 23:49:27 UTC, burjui wrote:
>> Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me:
>>
>> int[_] array = [ 1, 2, 3 ];
>
> alas, `_` is valid identifier, so `enum _ = 42; int[_] a;` is perfectly valid. dollar is simply most logical non-identifier character.

We can define static array without counting the elements as following:


enum array_ = [1u,2,3,4];
uint[array_.length] static_array = array_;
November 23, 2016
On Wednesday, 23 November 2016 at 18:54:35 UTC, Igor Shirkalin wrote:
> On Tuesday, 22 November 2016 at 00:08:05 UTC, ketmar wrote:
>> On Monday, 21 November 2016 at 23:49:27 UTC, burjui wrote:
>>> Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me:
>>>
>>> int[_] array = [ 1, 2, 3 ];
>>
>> alas, `_` is valid identifier, so `enum _ = 42; int[_] a;` is perfectly valid. dollar is simply most logical non-identifier character.
>
> We can define static array without counting the elements as following:
>
>
> enum array_ = [1u,2,3,4];
> uint[array_.length] static_array = array_;

there are workarounds, of course. yet i'll take mine `uint[$] a = [1u,2,3,4];` over that quoted mess at any time, without second thought. ;-)
November 23, 2016
On Wednesday, November 23, 2016 18:58:55 ketmar via Digitalmars-d-learn wrote:
> On Wednesday, 23 November 2016 at 18:54:35 UTC, Igor Shirkalin
>
> wrote:
> > On Tuesday, 22 November 2016 at 00:08:05 UTC, ketmar wrote:
> >> On Monday, 21 November 2016 at 23:49:27 UTC, burjui wrote:
> >>> Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me:
> >>>
> >>> int[_] array = [ 1, 2, 3 ];
> >>
> >> alas, `_` is valid identifier, so `enum _ = 42; int[_] a;` is perfectly valid. dollar is simply most logical non-identifier character.
> >
> > We can define static array without counting the elements as following:
> >
> >
> > enum array_ = [1u,2,3,4];
> > uint[array_.length] static_array = array_;
>
> there are workarounds, of course. yet i'll take mine `uint[$] a = [1u,2,3,4];` over that quoted mess at any time, without second thought. ;-)

It's nice, but it's non-standard. So, it seems to me that using it is just going to lead to problems like you ran into in this thread where you posted an example that wasn't valid D, and it'll make you that much more annoyed when you have to write code that _is_ standard D and can't use your enhancements. So, I really think that it would be better if you just used standard D, but obviously, that's up to you.

We really should add a helper for this to std.typecons though. Maybe I'll try and do something for it this holidy weekend...

- Jonathan M Davis

November 23, 2016
On Wednesday, 23 November 2016 at 19:15:52 UTC, Jonathan M Davis wrote:
> It's nice, but it's non-standard. So, it seems to me that using it is just going to lead to problems like you ran into in this thread where you posted an example that wasn't valid D, and it'll make you that much more annoyed when you have to write code that _is_ standard D and can't use your enhancements. So, I really think that it would be better if you just used standard D, but obviously, that's up to you.

for me, it is easier to "vanilize" the code later (if i need to, at all). yeah, sometimes non-vanilla code sneaks to where it doesn't belong, but it is rare, and doesn't invalidate the things that makes my life easier while i developing my projects. ;-) as i am unemployed now, i don't care if somebody is able to compile my code anymore.
November 24, 2016
On Friday, 18 November 2016 at 17:54:52 UTC, Igor Shirkalin wrote:
> The simpler - the better.
> After reading "D p.l." by A.Alexandrescu two years ago I have found my past dream. It's theory to start with. That book should be read at least two times especially if you have asm/c/c++/python3/math/physics background, and dealt with Watcom/Symantec C/C++ compilers (best to Walter Bright) with very high optimization goal. No stupid questions, just doing things.
> That was preface.
> Now I have server written in D for C++ pretty ancient client. Most things are three times shorter in size and clear (@clear? suffix). All programming paradigms were used.
> I have the same text in russian, but who has bothered russian(s)?
> The meaning of all of that is: powerfull attractive language with sufficient infrastructure with future. Just use it.
>
> [...]

My English is Bad than yours.

I am mot russian(s)、、、I am Chinese.