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 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
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