www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - the best language I have ever met(?)

reply Igor Shirkalin <mathsoft inbox.ru> writes:
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.

p.s. I'm excused for my primitive english.
Nov 18 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Fri, Nov 18, 2016 at 05:54:52PM +0000, Igor Shirkalin via
Digitalmars-d-learn 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.


Welcome, Igor!

Your sentiments reflect mine years ago when I first discovered D.  I
came from a C/C++/Perl background.  It was also Andrei's book that got
me started; in those early days documentation was scant and I didn't
know how to write idiomatic D code. But after I found TDPL, the rest was
history. :-)



 I have the same text in russian, but who has bothered russian(s)?


We have a few Russians on this forum, and I can understand some Russian
too. Though on this mailing list English is the language to use.



 The meaning of all of that is: powerfull attractive language with
 sufficient infrastructure with future. Just use it.


Yes, I agree!



 p.s. I'm excused for my primitive english.


[...]

Your English is understandable. That's good enough, I think. :-)


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. --
Christopher
Nov 18 2016
parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Friday, 18 November 2016 at 18:14:41 UTC, H. S. Teoh wrote:

 Welcome, Igor!


Hello, Teoh!

 Your sentiments reflect mine years ago when I first discovered 
 D.  I came from a C/C++/Perl background.  It was also Andrei's 
 book that got me started; in those early days documentation was 
 scant and I didn't know how to write idiomatic D code. But 
 after I found TDPL, the rest was history. :-)


I was a little bit afraid of my missunderstanding in terms of 
sentiments. You've got me right (I don't quite feel the meaning 
of that in these non-cyrillic letters:). But what I understand is 
the path you have walked and what I have in my mind.
Simple example about D: I spent two hours to write a line 
(borrowed from Python), related with lazy calculations, but 
finally I got it with deep great thinking, and it was like 
understanding of Moon alienation from Earth.


 We have a few Russians on this forum, and I can understand some 
 Russian too. Though on this mailing list English is the 
 language to use.


Sure, I don't have any doubt of it. I hope to be one of russian 
understandables here:)


 Your English is understandable. That's good enough, I think. :-)


Thank you, Teoh. That is very important for me to hear.

What is your using of D?
For me it is tool to develope other tools.

Igor
Nov 18 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Fri, Nov 18, 2016 at 07:26:56PM +0000, Igor Shirkalin via
Digitalmars-d-learn wrote:

 On Friday, 18 November 2016 at 18:14:41 UTC, H. S. Teoh wrote:

 Welcome, Igor!


 Hello, Teoh!

 
 Your sentiments reflect mine years ago when I first discovered D.  I
 came from a C/C++/Perl background.  It was also Andrei's book that
 got me started; in those early days documentation was scant and I
 didn't know how to write idiomatic D code. But after I found TDPL,
 the rest was history. :-)


 I was a little bit afraid of my missunderstanding in terms of
 sentiments.  You've got me right (I don't quite feel the meaning of
 that in these non-cyrillic letters:). But what I understand is the
 path you have walked and what I have in my mind.


Yes, I meant 'sentiments' as in опыта, not as in
сентметальность. :-)



 Simple example about D: I spent two hours to write a line (borrowed
 from Python), related with lazy calculations, but finally I got it
 with deep great thinking, and it was like understanding of Moon
 alienation from Earth.


Great!  Would you like to share the code snippet?


[...]

 What is your using of D?
 For me it is tool to develope other tools.


[...]

Sadly, I have not been able to use D in a professional capacity. My
coworkers are very much invested into C/C++ and have a very high level
of skepticism to anything else, in addition to resistance to adding new
toolchains (much less languages) to the current projects.  So my use of
D has mainly been in personal projects.  I do contribute to Phobos (the
standard library) every now and then, though.  It's my way of
"contributing to the cause" in the hopes that one day D may be more
widespread and accepted by the general programming community.


T

-- 
By understanding a machine-oriented language, the programmer will tend to use a
much more efficient method; it is much closer to reality. -- D. Knuth
Nov 18 2016
next sibling parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Friday, 18 November 2016 at 19:43:49 UTC, H. S. Teoh wrote:

 I was a little bit afraid of my missunderstanding in terms of 
 sentiments.  You've got me right (I don't quite feel the 
 meaning of that in these non-cyrillic letters:). But what I 
 understand is the path you have walked and what I have in my 
 mind.


 Yes, I meant 'sentiments' as in опыта, not as in 
 сентметальность. :-)


I used to mean 'sentiments' as "сентиметальность", but
"опыт - 
сын ошибок трудных" (Пушкин) is what realy in behind :)



 Simple example about D: I spent two hours to write a line 
 (borrowed from Python), related with lazy calculations, but 
 finally I got it with deep great thinking, and it was like 
 understanding of Moon alienation from Earth.





 Great!  Would you like to share the code snippet?


Sure. We have an array of uint. And we need to get a string of 
these values in hex separated with ','. In Python it looks like
<code>

      ', '.join(map(hex, array))
</code>


array.map!(v=>"%x".format(v)).join(", ")

 [...]

 What is your using of D?
 For me it is tool to develope other tools.


 [...]

 Sadly, I have not been able to use D in a professional 
 capacity. My coworkers are very much invested into C/C++ and 
 have a very high level of skepticism to anything else, in 
 addition to resistance to adding new toolchains (much less 
 languages) to the current projects.  So my use of D has mainly 
 been in personal projects.  I do contribute to Phobos (the 
 standard library) every now and then, though.  It's my way of 
 "contributing to the cause" in the hopes that one day D may be 
 more widespread and accepted by the general programming 
 community.


 T
Nov 18 2016
prev sibling parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Friday, 18 November 2016 at 19:43:49 UTC, H. S. Teoh wrote:

 I was a little bit afraid of my missunderstanding in terms of 
 sentiments.  You've got me right (I don't quite feel the 
 meaning of that in these non-cyrillic letters:). But what I 
 understand is the path you have walked and what I have in my 
 mind.


 Yes, I meant 'sentiments' as in опыта, not as in 
 сентметальность. :-)


I used to mean 'sentiments' as "сентиметальность", but
"опыт - 
сын ошибок трудных" (Пушкин) is what realy in behind :)



 Simple example about D: I spent two hours to write a line 
 (borrowed from Python), related with lazy calculations, but 
 finally I got it with deep great thinking, and it was like 
 understanding of Moon alienation from Earth.





 Great!  Would you like to share the code snippet?


Sure. Let we have a uint_array of values. And we need to get a 
string of these values in hex separated with ','. In Python it 
looks like

<code python>
      ', '.join(map(hex, uint_array))
</code python>

After 2 hours of brain breaking (as D newbie) I have come to:

<code D>
uint_array.map!(v=>"%x".format(v)).join(", ")
</code D>
Why 2 hours? Because I have started with 'joiner' function and 
aftewords found out the 'join'.

To my mind there is more simple form for this task in D (about 
formatting).


 What is your using of D?


 Sadly, I have not been able to use D in a professional 
 capacity. My coworkers are very much invested into C/C++ and 
 have a very high level of skepticism to anything else, in 
 addition to resistance to adding new toolchains (much less



 languages) to the current projects.  So my use of D has mainly 
 been in personal projects.  I do contribute to Phobos (the


Same here.
But my coworkers are not addicted to programming at all :)


 standard library) every now and then, though.  It's my way of 
 "contributing to the cause" in the hopes that one day D may be 
 more widespread and accepted by the general programming 
 community.


I don't hope about "D some day", I'm sure about that (5 to 30 
years).
The idea is "I D", not "I C++" :)
Nov 18 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Friday, 18 November 2016 at 20:31:57 UTC, Igor Shirkalin wrote:

 After 2 hours of brain breaking (as D newbie) I have come to:

 <code D>
 uint_array.map!(v=>"%x".format(v)).join(", ")
 </code D>
 Why 2 hours? Because I have started with 'joiner' function and 
 aftewords found out the 'join'.

 To my mind there is more simple form for this task in D (about 
 formatting).


sure ;-)

import std.stdio;
import std.format;
void main () {
   uint[$] a = [42, 69];
   string s = "%(%s, %)".format(a);
   writefln(s);
}
Nov 18 2016
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 18 November 2016 at 21:28:44 UTC, ketmar wrote:

 On Friday, 18 November 2016 at 20:31:57 UTC, Igor Shirkalin 
 wrote:

 After 2 hours of brain breaking (as D newbie) I have come to:

 <code D>
 uint_array.map!(v=>"%x".format(v)).join(", ")
 </code D>
 Why 2 hours? Because I have started with 'joiner' function and 
 aftewords found out the 'join'.

 To my mind there is more simple form for this task in D (about 
 formatting).


 sure ;-)

 import std.stdio;
 import std.format;
 void main () {
   uint[$] a = [42, 69];
   string s = "%(%s, %)".format(a);
   writefln(s);
 }


Please don't post non-d.
People might use it an then complain that it does not work.
Nov 18 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch wrote:

 Please don't post non-d.


it slipped accidentally, sorry. ;-)

for OP: `uint[2] a = [42, 69];` is the correct syntax.
Nov 18 2016
parent reply Patric Dexheimer <patric.dexheimer gmail.com> writes:
On Saturday, 19 November 2016 at 00:47:00 UTC, ketmar wrote:

 On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch 
 wrote:

 Please don't post non-d.


 it slipped accidentally, sorry. ;-)

 for OP: `uint[2] a = [42, 69];` is the correct syntax.


"uint[$] a = [42, 69];"

haha for a moment I thought that this was the way of D to create 
a fixed-size array without explicit setting the size (like what u 
can do in c++ :))
Nov 21 2016
next sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Monday, 21 November 2016 at 12:08:30 UTC, Patric Dexheimer 
wrote:

 On Saturday, 19 November 2016 at 00:47:00 UTC, ketmar wrote:

 On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch 
 wrote:

 Please don't post non-d.


 it slipped accidentally, sorry. ;-)

 for OP: `uint[2] a = [42, 69];` is the correct syntax.


 "uint[$] a = [42, 69];"

 haha for a moment I thought that this was the way of D to 
 create a fixed-size array without explicit setting the size 
 (like what u can do in c++ :))


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.
Nov 21 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
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 ;-).
Nov 21 2016
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Monday, November 21, 2016 12:08:30 Patric Dexheimer via Digitalmars-d-
learn wrote:

 On Saturday, 19 November 2016 at 00:47:00 UTC, ketmar wrote:

 On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch

 wrote:

 Please don't post non-d.


 it slipped accidentally, sorry. ;-)

 for OP: `uint[2] a = [42, 69];` is the correct syntax.


 "uint[$] a = [42, 69];"

 haha for a moment I thought that this was the way of D to create
 a fixed-size array without explicit setting the size (like what u
 can do in c++ :))


No. D doesn't have that, though it's easy enough to do the same thing with a
helper template. However, Ketmar seems to like to use his own fork of dmd
where he made changes to the language based on his preferences. IIRC, it was
proposed at one point that $ be used in this manner to create a static array
while inferring its size (it might have even had a PR which was rejected),
and presumably, Ketmar added it to his own compiler, because he liked the
feature. But for better or worse, it's not standard D, and if the PR was
rejected like I think it was, then it likely never will become standard D.
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
Nov 21 2016
next sibling parent Namespace <rswhite4 gmail.com> writes:
On Monday, 21 November 2016 at 12:44:47 UTC, Jonathan M Davis 
wrote:

 On Monday, November 21, 2016 12:08:30 Patric Dexheimer via 
 Digitalmars-d- learn wrote:
 No. D doesn't have that, though it's easy enough to do the same 
 thing with a helper template. However, Ketmar seems to like to 
 use his own fork of dmd where he made changes to the language 
 based on his preferences. IIRC, it was proposed at one point 
 that $ be used in this manner to create a static array while 
 inferring its size (it might have even had a PR which was 
 rejected), and presumably, Ketmar added it to his own compiler, 
 because he liked the feature. But for better or worse, it's not 
 standard D, and if the PR was rejected like I think it was, 
 then it likely never will become standard D. 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


https://p0nce.github.io/d-idioms/# nogc-Array-Literals:-Breaking-the-Limits
Nov 21 2016
prev sibling next sibling parent reply burjui <bytefu gmail.com> writes:
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 ];
Nov 21 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.
Nov 21 2016
parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
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_;
Nov 23 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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. ;-)
Nov 23 2016
next sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
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
Nov 23 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
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.
Nov 23 2016
prev sibling parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Wednesday, 23 November 2016 at 18:58:55 UTC, ketmar wrote:

 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. ;-)


I think you may write it (I mean actual D) with using some 
template like this:

auto array = static_array!uint(1, 2, 3, 4)

Could you please help to write down this template in the best and 
clear manner?
Nov 25 2016
next sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Friday, November 25, 2016 14:27:39 Igor Shirkalin via Digitalmars-d-learn 
wrote:

 On Wednesday, 23 November 2016 at 18:58:55 UTC, ketmar wrote:

 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. ;-)


 I think you may write it (I mean actual D) with using some
 template like this:

 auto array = static_array!uint(1, 2, 3, 4)

 Could you please help to write down this template in the best and
 clear manner?


That's easy. The problem is if you want it to have the same semantics as

uint[4] arr = [1, 2, 3, 4];

In particular, VRP (Value Range Propagation) is a problem. This compiles

ubyte[4] arr = [1, 2, 3, 4];

because each of the arguments is known to fit in a ubyte. However, making

auto arr = staticArray!ubyte(1, 2, 3, 4);

do the same without forcing a cast is difficult. And if you force the cast,
then it's not equivalent anymore, because something like

ubyte[4] arr = [1, 2, 3, 900];

would not compile. And surprisingly, having the function take a dynamic
array doesn't fix that problem (though maybe that's something that we could
talk the dmd devs into improving). e.g.

auto arr = staticArray!ubyte([1, 2, 3, 4]);

doesn't compile either. The most straightforward implementations are
something like

T[n] staticArray(T, size_t n)(auto ref T[n] arr)
{
    return arr;
}

or

auto staticArray(Args...)(Args args)
{
    CommonType!Args[Args.length] arr = [args];
    return arr;
}

but I don't know if the VRP problem is solvable or not without some compiler
improvements. If there's a clever enough implementation to get VRP with a
function like this with the current language, I haven't figured it out yet.

- Jonathan M Davis
Nov 25 2016
parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Friday, 25 November 2016 at 14:51:52 UTC, Jonathan M Davis 
wrote:

 I think you may write it (I mean actual D) with using some
 template like this:

 auto array = static_array!uint(1, 2, 3, 4)

 Could you please help to write down this template in the best 
 and clear manner?


 That's easy. The problem is if you want it to have the same 
 semantics as

 uint[4] arr = [1, 2, 3, 4];

 In particular, VRP (Value Range Propagation) is a problem. This 
 compiles

 ubyte[4] arr = [1, 2, 3, 4];

 because each of the arguments is known to fit in a ubyte. 
 However, making

 auto arr = staticArray!ubyte(1, 2, 3, 4);

 do the same without forcing a cast is difficult. And if you 
 force the cast, then it's not equivalent anymore, because 
 something like

 ubyte[4] arr = [1, 2, 3, 900];

 would not compile. And surprisingly, having the function take a 
 dynamic array doesn't fix that problem (though maybe that's 
 something that we could talk the dmd devs into improving). e.g.


To mine mind it is not a problem because when you write you think 
what you write (or you are right). Morover compiler will always 
tell you are wrong if you make 256 to be ubyte implicity.


 auto arr = staticArray!ubyte([1, 2, 3, 4]);

 doesn't compile either. The most straightforward 
 implementations are something like


Why? Is it since [1, 2, 3, 4] is int[4] by default?


 T[n] staticArray(T, size_t n)(auto ref T[n] arr)
 {
     return arr;
 }

 or

 auto staticArray(Args...)(Args args)
 {
     CommonType!Args[Args.length] arr = [args];
     return arr;
 }


Great! Thank you. I should take more precise look at std.traits


 but I don't know if the VRP problem is solvable or not without 
 some compiler improvements. If there's a clever enough 
 implementation to get VRP with a function like this with the 
 current language, I haven't figured it out yet.

 - Jonathan M Davis


As I noticed, to my mind it is not a hindrance to write 
deliberate things.

- Igor Shirkalin
Nov 25 2016
next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Friday, November 25, 2016 15:59:48 Igor Shirkalin via Digitalmars-d-learn 
wrote:

 On Friday, 25 November 2016 at 14:51:52 UTC, Jonathan M Davis

 auto arr = staticArray!ubyte([1, 2, 3, 4]);

 doesn't compile either. The most straightforward
 implementations are something like


 Why? Is it since [1, 2, 3, 4] is int[4] by default?


It's because [1, 2, 3, 4] is inferred to be int[], and _then_ the compiler
tries to instantiate the templated function, whereas with

ubyte[4] = [1, 2, 3, 4];

the compiler looks at is one thing and determines that the array literal can
be ubyte[], and it works. And if staticArray is a variadic template instead
of taking an array literal, e.g.

auto arr = staticArray!ubyte(1, 2, 3, 4);

then the values all get inferred to be int, and when it tries to assign the
arguments to the ubyte[4], it doesn't compile, because they're int and not
ubyte, which then means that you're forced to either cast the elements to
ubyte at the call site

auto arr = staticArray!ubyte(cast(ubyte)1,
                             cast(ubyte)2,
                             cast(ubyte)3,
                             cast(ubyte)4);

or staticArray itself has to do the cast, but if staticArray itself does the
cast, then something like

auto arr = staticArray!ubyte(1, 2, 900);

would compile without error, and you'd end up with whatever cast(ubyte)900
is. I'd _like_ to be able to find a way to make it so that the semantics of
the staticArray function are identical to

ubyte[4] = [1, 2, 3, 4];

except that the length is inferred, and I'm coming to the conclusion that
it's not possible. That being the case, I'm leaning towards going with

T[n] staticArray(T, size_t n)(auto ref T[n] arr)
{
    return arr;
}

and opening an enhancement request to make the compiler smart enough that

auto arr = staticArray!ubyte([1, 2, 3, 4]);

would work. I don't see

auto arr = staticArray!ubyte(1, 2, 3, 4);

ever working unless the symbols being passed in could be examined at compile
time, and I don't think that they can be - just their types.

- Jonathan M Davis
Nov 25 2016
prev sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Friday, November 25, 2016 08:26:11 Jonathan M Davis via Digitalmars-d-
learn wrote:

 and opening an enhancement request to make the compiler smart enough that

 auto arr = staticArray!ubyte([1, 2, 3, 4]);

 would work.


Opened: https://issues.dlang.org/show_bug.cgi?id=16779

And regardless of this particular use case, it's something that arguably
should work.

- Jonathan M Davis
Nov 25 2016
prev sibling next sibling parent Artur Skawina via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On 11/25/16 15:51, Jonathan M Davis via Digitalmars-d-learn wrote:

 On Friday, November 25, 2016 14:27:39 Igor Shirkalin via Digitalmars-d-learn 
 wrote:

 I think you may write it (I mean actual D) with using some
 template like this:

 auto array = static_array!uint(1, 2, 3, 4)

 Could you please help to write down this template in the best and
 clear manner?


 
 That's easy. The problem is if you want it to have the same semantics as
 
 uint[4] arr = [1, 2, 3, 4];
 
 In particular, VRP (Value Range Propagation) is a problem. This compiles
 
 ubyte[4] arr = [1, 2, 3, 4];
 
 because each of the arguments is known to fit in a ubyte. However, making
 
 auto arr = staticArray!ubyte(1, 2, 3, 4);
 
 do the same without forcing a cast is difficult. [...]


   enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS;
   auto arr = staticArray!(ubyte, [1, 2, 3, 4]);

artur
Nov 25 2016
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Friday, 25 November 2016 at 14:27:39 UTC, Igor Shirkalin wrote:

 On Wednesday, 23 November 2016 at 18:58:55 UTC, ketmar wrote:

 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. ;-)


 I think you may write it (I mean actual D) with using some 
 template like this:


yeah. but i'm not Andrei, i don't believe that the only compiler 
task is to resolve templated code. ;-) i.e. Andrei believes that 
everything (and more) should be moved out of compiler core and 
done with library templates. Andrei is genius, for sure, but he 
is living somewhere in future, where our PCs are not bound by 
memory, CPU, and other silly restrictions. ;-)

tl;dr: using template for this sux.
Nov 25 2016
next sibling parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Friday, 25 November 2016 at 19:16:43 UTC, ketmar wrote:

 yeah. but i'm not Andrei, i don't believe that the only 
 compiler task is to resolve templated code. ;-) i.e. Andrei 
 believes that everything (and more) should be moved out of 
 compiler core and done with library templates. Andrei is 
 genius, for sure, but he is living somewhere in future, where 
 our PCs are not bound by memory, CPU, and other silly 
 restrictions. ;-)

 tl;dr: using template for this sux.


Nice to meet you, Andrei!

Yes, in mathematics we are more servants than gentlemen (Charles 
Hermite).
Oct 10 2017
prev sibling parent Igor <stojkovic.igor gmail.com> writes:
On Friday, 25 November 2016 at 19:16:43 UTC, ketmar wrote:

 On Friday, 25 November 2016 at 14:27:39 UTC, Igor Shirkalin 
 wrote:

 On Wednesday, 23 November 2016 at 18:58:55 UTC, ketmar wrote:

 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. ;-)


 I think you may write it (I mean actual D) with using some 
 template like this:


 yeah. but i'm not Andrei, i don't believe that the only 
 compiler task is to resolve templated code. ;-) i.e. Andrei 
 believes that everything (and more) should be moved out of 
 compiler core and done with library templates. Andrei is 
 genius, for sure, but he is living somewhere in future, where 
 our PCs are not bound by memory, CPU, and other silly 
 restrictions. ;-)

 tl;dr: using template for this sux.


I just don't understand how is it worth to add to a language that 
instead of typing someArray.length you can just type $ but it is 
not ok to add to the language the same thing for static array 
size...
Oct 13 2017
prev sibling parent reply MGW <mgw yandex.ru> writes:
On Wednesday, 23 November 2016 at 18:54:35 UTC, Igor Shirkalin 
wrote:
Igor, is the good Russian-speaking forum

https://vk.com/vk_dlang.

There are articles on GUI and other aspects of dlang.
Nov 24 2016
parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Friday, 25 November 2016 at 07:17:18 UTC, MGW wrote:

 On Wednesday, 23 November 2016 at 18:54:35 UTC, Igor Shirkalin 
 wrote:
 Igor, is the good Russian-speaking forum

 https://vk.com/vk_dlang.

 There are articles on GUI and other aspects of dlang.


Thank you, I'll tale a look at it for sure.
Nov 25 2016
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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. ;-)
Nov 21 2016
prev sibling parent Daniel Kozak via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
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
Nov 21 2016
prev sibling parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch wrote:

 import std.stdio;
 import std.format;
 void main () {
   uint[$] a = [42, 69];
   string s = "%(%s, %)".format(a);
   writefln(s);
 }


 Please don't post non-d.
 People might use it an then complain that it does not work.


Let these people to complain. ;)
Nov 19 2016
prev sibling parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Friday, 18 November 2016 at 21:28:44 UTC, ketmar wrote:

 On Friday, 18 November 2016 at 20:31:57 UTC, Igor Shirkalin 
 wrote:

 After 2 hours of brain breaking (as D newbie) I have come to:

 <code D>
 uint_array.map!(v=>"%x".format(v)).join(", ")
 </code D>
 Why 2 hours? Because I have started with 'joiner' function and 
 aftewords found out the 'join'.

 To my mind there is more simple form for this task in D (about 
 formatting).


 sure ;-)

 import std.stdio;
 import std.format;
 void main () {
   uint[$] a = [42, 69];
   string s = "%(%s, %)".format(a);
   writefln(s);
 }


Accepted.
Is it really needed to call 'writefln'? I mean 'f'.
Nov 19 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Saturday, 19 November 2016 at 17:12:13 UTC, Igor Shirkalin 
wrote:

   string s = "%(%s, %)".format(a);
   writefln(s);
 }


 Accepted.
 Is it really needed to call 'writefln'? I mean 'f'.


no. it's a leftover from the code without format. it originally 
was `writefln("%(%s, %)", a);`, but i wanted to show `format` 
function too, and forgot to remove `f`. actually, it is a BUG to 
call `writefln` here, 'cause who knows, `s` may contain '%', and 
then boom! all hell broke loose. ;-)
Nov 19 2016
parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Saturday, 19 November 2016 at 20:54:32 UTC, ketmar wrote:

 On Saturday, 19 November 2016 at 17:12:13 UTC, Igor Shirkalin 
 wrote:

   string s = "%(%s, %)".format(a);
   writefln(s);
 }


 Accepted.
 Is it really needed to call 'writefln'? I mean 'f'.


 no. it's a leftover from the code without format. it originally 
 was `writefln("%(%s, %)", a);`, but i wanted to show `format` 
 function too, and forgot to remove `f`. actually, it is a BUG 
 to call `writefln` here, 'cause who knows, `s` may contain '%', 
 and then boom! all hell broke loose. ;-)


Got it! Thanks.
Nov 19 2016
prev sibling parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Fri, Nov 18, 2016 at 11:43:49AM -0800, H. S. Teoh via Digitalmars-d-learn
wrote:
[...]

 Yes, I meant 'sentiments' as in опыта, not as in
сентметальность. :-)


[...]

Sorry, typo. I meant сентиментальности. But I think you
understand what
I mean. :-)


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC
Nov 18 2016
next sibling parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Friday, 18 November 2016 at 19:47:17 UTC, H. S. Teoh wrote:

 Yes, I meant 'sentiments' as in опыта, not as in 
 сентметальность. :-)


 [...]
 Sorry, typo. I meant сентиментальности. But I think you 
 understand what I mean. :-)


Oh, I think you understand what you think what I mean :)
Nov 18 2016
prev sibling parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Friday, 18 November 2016 at 19:47:17 UTC, H. S. Teoh wrote:

 On Fri, Nov 18, 2016 at 11:43:49AM -0800, H. S. Teoh via 
 Digitalmars-d-learn wrote: [...]

 Yes, I meant 'sentiments' as in опыта, not as in 
 сентметальность. :-)


 [...]

 Sorry, typo. I meant сентиментальности. But I think you 
 understand what I mean. :-)


 T


I Think there's a bug. When I'm answerring a message, and if my 
recipient send me the message, and after I press 'send' button, 
my message is duplicated. Simple bug to repare.
Nov 18 2016
prev sibling next sibling parent Dsby <dushibaiyu yahoo.com> writes:
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.
Nov 23 2016
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Friday, November 25, 2016 17:03:32 Artur Skawina via Digitalmars-d-learn 
wrote:

 On 11/25/16 15:51, Jonathan M Davis via Digitalmars-d-learn wrote:

 On Friday, November 25, 2016 14:27:39 Igor Shirkalin via
 Digitalmars-d-learn>
 wrote:

 I think you may write it (I mean actual D) with using some
 template like this:

 auto array = static_array!uint(1, 2, 3, 4)

 Could you please help to write down this template in the best and
 clear manner?


 That's easy. The problem is if you want it to have the same semantics as

 uint[4] arr = [1, 2, 3, 4];

 In particular, VRP (Value Range Propagation) is a problem. This compiles

 ubyte[4] arr = [1, 2, 3, 4];

 because each of the arguments is known to fit in a ubyte. However,
 making

 auto arr = staticArray!ubyte(1, 2, 3, 4);

 do the same without forcing a cast is difficult. [...]


    enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS;
    auto arr = staticArray!(ubyte, [1, 2, 3, 4]);


That won't work with variables. e.g.

ubyte a;
auto arr = staticArray!(ubyte, [1, 2, 3, 4, a]);

would fail to compile. It only works when all of the values are known at
compile time, whereas

ubyte a;
ubyte[5] arr = [1, 2, 3, 4, a];

would compile just fine.

- Jonathan M Davis
Nov 25 2016
prev sibling next sibling parent Artur Skawina via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On 11/25/16 17:30, Jonathan M Davis via Digitalmars-d-learn wrote:

 On Friday, November 25, 2016 17:03:32 Artur Skawina via Digitalmars-d-learn 
 wrote:

 On 11/25/16 15:51, Jonathan M Davis via Digitalmars-d-learn wrote:

 On Friday, November 25, 2016 14:27:39 Igor Shirkalin via
 Digitalmars-d-learn>
 wrote:

 I think you may write it (I mean actual D) with using some
 template like this:

 auto array = static_array!uint(1, 2, 3, 4)

 Could you please help to writeown this template in the best and
 clear manner?


 That's easy. The problem is if you want it to have the same semantics as

 uint[4] arr = [1, 2, 3, 4];

 In particular, VRP (Value Range Propagation) is a problem. This compiles

 ubyte[4] arr = [1, 2, 3, 4];

 because each of the arguments is known to fit in a ubyte. However,
 making

 auto arr = staticArray!ubyte(1, 2, 3, 4);

 do the same without forcing a cast is difficult. [...]


    enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS;
    auto arr = staticArray!(ubyte, [1, 2, 3, 4]);


 
 That won't work with variables. e.g.
 
 ubyte a;
 auto arr = staticArray!(ubyte, [1, 2, 3, 4, a]);
 
 would fail to compile. It only works when all of the values are known at
 compile time, whereas
 
 ubyte a;
 ubyte[5] arr = [1, 2, 3, 4, a];
 
 would compile just fine.


Now you're trying to change the scope. Of course this is a hack,
that's only useful in certain contexts, such as initializing static
arrays with known values, which this subthread is about.

It actually makes the source code (look) worse; having to use lots of 
such module- or project-local hacks doesn't scale, and is a symptom
of language problems.

The point, however, was that that is the only way to get VRP - the
values must be available at CT for VRP to work effectively.
Your suggestion to "fix" VRP would break CTFE (different implicit
conversions would be allowed at CT and RT) and could result in
code compiling or not depending on the function arguments used,
possibly in a very unintuitive way (eg depending on if the function
args values happened to be CTFE-able).

artur
Nov 25 2016
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Friday, November 25, 2016 18:20:11 Artur Skawina via Digitalmars-d-learn 
wrote:

 On 11/25/16 17:30, Jonathan M Davis via Digitalmars-d-learn wrote:

 On Friday, November 25, 2016 17:03:32 Artur Skawina via

    enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS;
    auto arr = staticArray!(ubyte, [1, 2, 3, 4]);


 That won't work with variables. e.g.

 ubyte a;
 auto arr = staticArray!(ubyte, [1, 2, 3, 4, a]);

 would fail to compile. It only works when all of the values are known at
 compile time, whereas

 ubyte a;
 ubyte[5] arr = [1, 2, 3, 4, a];

 would compile just fine.


 Now you're trying to change the scope. Of course this is a hack,
 that's only useful in certain contexts, such as initializing static
 arrays with known values, which this subthread is about.


How is it changing the scope? What has been asked for on several occasions -
and what int[$] was supposed to fix - was the ability to intialize a static
array while inferring its size.

ubyte a;
ubyte[5] arr = [1, 2, 3, 4, a];

is a perfectly legitimate example of initializing a static array, and
there's no reason why it shouldn't be a goal to have it work with a function
that infers the size of the static array.


 It actually makes the source code (look) worse; having to use lots of
 such module- or project-local hacks doesn't scale, and is a symptom
 of language problems.

 The point, however, was that that is the only way to get VRP - the
 values must be available at CT for VRP to work effectively.
 Your suggestion to "fix" VRP would break CTFE (different implicit
 conversions would be allowed at CT and RT) and could result in
 code compiling or not depending on the function arguments used,
 possibly in a very unintuitive way (eg depending on if the function
 args values happened to be CTFE-able).


We'd actually have it right now with

T[n] staticArray(T, size_t n)(auto ref T[n] arr)
{
    return arr;
}

except that VRP only works right now if no inferrence is done when
instantiating the template.

auto sa = staticArray!(ubyte, 4)([1, 2, 3, 4]);

compiles just fine, but that obviously defeats the purpose of the template.
If the compiler is improved so that

auto sa = staticArray!ubyte([1, 2, 3, 4]);

also works with VRP, then everything works just like it would with

ubyte a;
ubyte[5] arr = [1, 2, 3, 4, a];

except that with the function, the size would be inferred.

ubyte a;
auto arr = staticArray!ubyte([1, 2, 3, 4, a]);

And until

https://issues.dlang.org/show_bug.cgi?id=16779

is fixed, the above definition of staticArray works perfectly fine except
for the fact that you lose out on VRP. And once 16779 is fixed, we have a
complete solution, whereas any solution that would currently work with VRP
permanently loses out on being able to have any variables used in
initializing the array.

- Jonathan M Davis
Nov 25 2016
prev sibling next sibling parent Artur Skawina via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On 11/25/16 18:33, Jonathan M Davis via Digitalmars-d-learn wrote:

 On Friday, November 25, 2016 18:20:11 Artur Skawina via Digitalmars-d-learn 
 wrote:

 On 11/25/16 17:30, Jonathan M Davis via Digitalmars-d-learn wrote:

 On Friday, November 25, 2016 17:03:32 Artur Skawina via

    enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS;
    auto arr = staticArray!(ubyte, [1, 2, 3, 4]);


 That won't work with variables. e.g.

 ubyte a;
 auto arr = staticArray!(ubyte, [1, 2, 3, 4, a]);

 would fail to compile. It only works when all of the values are known at
 compile time, whereas

 ubyte a;
 ubyte[5] arr = [1, 2, 3, 4, a];

 would compile just fine.


 Now you're trying to change the scope. Of course this is a hack,
 that's only useful in certain contexts, such as initializing static
 arrays with known values, which this subthread is about.


 
 How is it changing the scope? What has been asked for on several occasions -
 and what int[$] was supposed to fix - was the ability to intialize a static
 array while inferring its size.


It's a known language limitation, which can be worked around using
hacks such as the one I showed, that help in the very common cases
that appeared in this thread, add zero RT costs and work with VRP.
I didn't realize you were suggesting to use the function helper
route for the general case - no scope change, sorry.


 ubyte a;
 ubyte[5] arr = [1, 2, 3, 4, a];
 
 is a perfectly legitimate example of initializing a static array, and
 there's no reason why it shouldn't be a goal to have it work with a function
 that infers the size of the static array.


The problem with such a function is that, just like every other function,
it's type can not depend on RT data, and that `typeof([1,a])` is `int[]`.
The information is lost at the function boundary. So the possible
improvements are a) changing the array literal semantics, and b)
improving IFTI. 


 We'd actually have it right now with
 
 T[n] staticArray(T, size_t n)(auto ref T[n] arr)
 {
     return arr;
 }
 
 except that VRP only works right now if no inferrence is done when
 instantiating the template.
 
 auto sa = staticArray!(ubyte, 4)([1, 2, 3, 4]);
 
 compiles just fine, but that obviously defeats the purpose of the template.
 If the compiler is improved so that
 
 auto sa = staticArray!ubyte([1, 2, 3, 4]);
 
 also works with VRP, then everything works just like it would with
 
 ubyte a;
 ubyte[5] arr = [1, 2, 3, 4, a];
 
 except that with the function, the size would be inferred.
 
 ubyte a;
 auto arr = staticArray!ubyte([1, 2, 3, 4, a]);


IOW you want to improve IFTI, so that `n` is inferred from the
length of the passed argument. That would indeed work for array
literals and CTFE-able expressions. Any improvement to IFTI is a
good thing, but the RT cost of this helper could be high if it ever
doesn't get inlined and completely optimized away.
If the cost isn't an issue and a different syntax is acceptable
then this should already work:

   template staticArray(T, E...) {
      T[E.length] staticArray()  property { return [E]; }
   }
   template staticArray(E...) {
      typeof([E][0])[E.length] staticArray()  property { return [E]; }
   }

   ubyte a;
   auto sa = staticArray!(ubyte, 1, 2, 3, 4, a);
   auto sb = staticArray!(1, 2, 3, 4, a);

artur
Nov 25 2016
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Saturday, November 26, 2016 00:43:04 Artur Skawina via Digitalmars-d-
learn wrote:

 IOW you want to improve IFTI, so that `n` is inferred from the
 length of the passed argument. That would indeed work for array
 literals and CTFE-able expressions. Any improvement to IFTI is a
 good thing, but the RT cost of this helper could be high if it ever
 doesn't get inlined and completely optimized away.


That's what pragma(inline, true) is for. And if someone wants a different
solution that's completely compile-time and doesn't work with variables,
then fine. I'm talking about adding something to the standard library, and
for that, I think that a solution that is as close as possible to being
identical to simply declaring the static array with the length is what would
be appropriate.


 If the cost isn't an issue and a different syntax is acceptable
 then this should already work:

    template staticArray(T, E...) {
       T[E.length] staticArray()  property { return [E]; }
    }
    template staticArray(E...) {
       typeof([E][0])[E.length] staticArray()  property { return [E]; }
    }

    ubyte a;
    auto sa = staticArray!(ubyte, 1, 2, 3, 4, a);
    auto sb = staticArray!(1, 2, 3, 4, a);


I'm not married to the syntax. I tried that syntax, but I couldn't figure
out how to get it to work with runtime values. The closest that I could come
up with was what I showed before, and the fact that IFTI wasn't smart enough
with VRP was the only blocker. It looks like you've found a way to do it
with all template arguments though, which is fine with me.

- Jonathan M Davis
Nov 28 2016
parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Monday, 28 November 2016 at 16:15:23 UTC, Jonathan M Davis 
wrote:

 That's what pragma(inline, true) is for. And if someone wants a 
 different solution that's completely compile-time and doesn't 
 work with variables, then fine. I'm talking about adding 
 something to the standard library, and for that, I think that a 
 solution that is as close as possible to being identical to 
 simply declaring the static array with the length is what would 
 be appropriate.


...


 I'm not married to the syntax. I tried that syntax, but I 
 couldn't figure out how to get it to work with runtime values.


Can I insert my own opinion about static arrays with programmers' 
unknown size?
Being the practical developer I can't imagine the situation where 
it is really needed. I hope D is not for theoretical goals only 
but for practical ones first.
If we know the size of our future array we tell that to the 
compiler. If we don't know the size of our future static array we 
write an external generator to produce that. I really don't know 
places where I want static array to be unknown size inline 
(perhaps, except for debugging purposes). Concluding, the 
designer knows he's achived the perfection if there is nothing to 
remove, but not to add.

Igor Shirkalin
Dec 02 2016
prev sibling parent reply eugene <egordeev18 gmail.com> writes:
On Friday, 18 November 2016 at 17:54:52 UTC, Igor Shirkalin wrote:

 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.

 p.s. I'm excused for my primitive english.


how much money did you earn using D language?
Dec 03 2016
parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Saturday, 3 December 2016 at 15:02:35 UTC, eugene wrote:

 On Friday, 18 November 2016 at 17:54:52 UTC, Igor Shirkalin 
 wrote:

 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.

 p.s. I'm excused for my primitive english.


 how much money did you earn using D language?


I didnt count, but its about ten thousend a year, i.e. nothing. 
You earn ten times more of me. Ask me enything more.
Dec 05 2016
parent reply eugene <egordeev18 gmail.com> writes:
On Monday, 5 December 2016 at 16:07:41 UTC, Igor Shirkalin wrote:

 I didnt count, but its about ten thousend a year, i.e. nothing.


if you earned nothing using D language why do you recommend it?)))
People usually earn money using programming langs.
Dec 05 2016
parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Monday, 5 December 2016 at 16:39:33 UTC, eugene wrote:

 On Monday, 5 December 2016 at 16:07:41 UTC, Igor Shirkalin 
 wrote:

 I didnt count, but its about ten thousend a year, i.e. nothing.


 if you earned nothing using D language why do you recommend 
 it?)))
 People usually earn money using programming langs.


some people have nothing about science. Some of them are god's 
addicted. I don't think D is here. We are out of here. We should 
go to facebook and keep here if you take it. that's it.
Dec 05 2016
parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Monday, 5 December 2016 at 17:27:21 UTC, Igor Shirkalin wrote:

 On Monday, 5 December 2016 at 16:39:33 UTC, eugene wrote:

 On Monday, 5 December 2016 at 16:07:41 UTC, Igor Shirkalin 
 wrote:

 I didnt count, but its about ten thousend a year, i.e. 
 nothing.


 if you earned nothing using D language why do you recommend 
 it?)))
 People usually earn money using programming langs.


 some people have nothing about science. Some of them are god's 
 addicted. I don't think D is here. We are out of here. We 
 should go to facebook and keep here if you take it. that's it.


I think we have to stop.
Dec 05 2016