On 10/22/14 1:17 AM, Domingo Alvarez Duarte wrote:
Let's talk about libraries now, there is some silly things like
associative array not having a "clear/lenght=0" way to reset it, and
people sugest create templates that does:
foreach(string key; aa.keys) aa.remove(key);
Annoying...
https://g
On Friday, October 24, 2014 11:03:11 Jakob Ovrum via Digitalmars-d wrote:
> On Wednesday, 22 October 2014 at 07:42:22 UTC, Jonathan M Davis
>
> via Digitalmars-d wrote:
> > Well, the reality of the matter is that you can't truly clear
> > it safely,
> > though we could definitely get closer. The in
On Wednesday, 22 October 2014 at 07:42:22 UTC, Jonathan M Davis
via Digitalmars-d wrote:
Well, the reality of the matter is that you can't truly clear
it safely,
though we could definitely get closer. The in operator gives
pointer access to
the internals, and the byKey and byValue may do the sam
Though some refactorings are so simple, they can be done for
string mixins too, e.g.
https://issues.dlang.org/show_bug.cgi?id=3850
Ah, ok, I thought, you said CTFE is a source-to-source killer.
On Thursday, 23 October 2014 at 13:54:35 UTC, Kagamin wrote:
Able to perform complex transformations, e.g. D to SQL. Or
generate parser from syntax definition, like what pegged does.
I'm not really sure where you are heading. I am against string
mixins, not CTFE.
Able to perform complex transformations, e.g. D to SQL. Or
generate parser from syntax definition, like what pegged does.
On Thursday, 23 October 2014 at 11:45:46 UTC, Kagamin wrote:
On Wednesday, 22 October 2014 at 08:44:44 UTC, Ola Fosheim
Grøstad wrote:
On the other hand, C macros can be expanded and then you do
source-to-source translation. With D mixins you might have to
evaluate CTFE first? That's a source-t
On Wednesday, 22 October 2014 at 08:44:44 UTC, Ola Fosheim
Grøstad wrote:
On the other hand, C macros can be expanded and then you do
source-to-source translation. With D mixins you might have to
evaluate CTFE first? That's a source-to-source killer.
If it's fairly complex, like turing-complet
On Wednesday, 22 October 2014 at 12:17:32 UTC, Dejan Lekic wrote:
It is easy to write ugly code in D without string mixins.
Just take a look at the (ab)use of UFCS...
I am not a fan of UFCS either… I think it is nice to be able to
extend aggregates with new member functions, UFCS isn't require
On Wednesday, 22 October 2014 at 08:14:24 UTC, Ola Fosheim
Grøstad wrote:
2. Easy to write ugly code: It suffers from the same issues as
macros.
It is easy to write ugly code in D without string mixins.
Just take a look at the (ab)use of UFCS...
On Wednesday, 22 October 2014 at 08:27:53 UTC, bearophile wrote:
Ola Fosheim Grøstad:
2. Easy to write ugly code: It suffers from the same issues as
macros.
Do you mean C macros? I think this is not true.
Not C macros, because they are free form and happen before
parsing.
On the other ha
Ola Fosheim Grøstad:
2. Easy to write ugly code: It suffers from the same issues as
macros.
Do you mean C macros? I think this is not true.
3. Language integration: It is desirable to have an application
level language that can integrate well with a low level
language when calling out to s
On Wednesday, 22 October 2014 at 07:46:18 UTC, bearophile wrote:
Ola Fosheim Grøstad:
I also want to see string mixins removed from phobos. It is a
very ugly feature.
What are your problems with those strings?
1. Source level analysis: Hard to write programs that transform
source.
2. Easy
Ola Fosheim Grøstad:
I think the overrated C++ standard library has influenced
phobos too much.
I agree.
I also want to see string mixins removed from phobos. It is a
very ugly feature.
What are your problems with those strings?
Bye,
bearophile
On Wednesday, October 22, 2014 06:59:02 Jakob Ovrum via Digitalmars-d wrote:
> On Wednesday, 22 October 2014 at 06:42:06 UTC, Ali Çehreli wrote:
> > On 10/21/2014 11:06 PM, thedeemon wrote:
> >> A[B] freshCleanAA;
> >> aa = freshCleanAA;
> >>
> >> (where A[B] denotes the type of aa)
> >> Th
On Wednesday, 22 October 2014 at 06:42:06 UTC, Ali Çehreli wrote:
On 10/21/2014 11:06 PM, thedeemon wrote:
A[B] freshCleanAA;
aa = freshCleanAA;
(where A[B] denotes the type of aa)
That's it!
Alternative:
A[B] aa;
aa = aa.init;
Ali
`aa.init` is just `null`, which illustra
On 10/21/2014 11:06 PM, thedeemon wrote:
A[B] freshCleanAA;
aa = freshCleanAA;
(where A[B] denotes the type of aa)
That's it!
Alternative:
A[B] aa;
aa = aa.init;
Ali
There is no backport/bug fix for the stable releases like gcc
or other well know software, gcc has at least the latest 3
stable version maintained, when a bug is found it's fixed on
all of the maintained versions that suffer from it.
Yes, I agree. I've also complained about not having a stable
On Wednesday, 22 October 2014 at 05:17:54 UTC, Domingo Alvarez
Duarte wrote:
There is no backport/bug fix for the stable releases
I understand now for each release 2.0XX there can be some bugfix
releases like 2.0XX.Y. For example, 2.066.1 is a bugfix release
for 2.066.
Let's talk about l
Hello !
I'll start here a place to blame the D language with the intent
of register here the dark sides of the language and it's
libraries with the hope that it will drive efforts to fix then.
First a bit of my experience with the D language, I hear about it
some years ago and it was an inte
21 matches
Mail list logo
