Do you seen anything wrong in this code? It compiles with no errors:
enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
static assert(data[4] == "yellow");
void main() {}
Yet that code asserts. it's an excellent example of why a sloppy
compiler/language sooner or later comes ba
Nagging is one way to accomplish change, but it's sure annoying. If you feel
the feature is import, you know where to get the source. Give it a shot.
Contribution of code is oh so much more valuable than a constant stream of "you
should change..."
Repeatedly claiming that Walter ignores 'X' is a
On Wed, 10 Nov 2010 20:34:07 -0600, bearophile
wrote:
Do you seen anything wrong in this code? It compiles with no errors:
enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
static assert(data[4] == "yellow");
void main() {}
Yet that code asserts. it's an excellent example
On Wednesday 10 November 2010 18:56:02 Brad Roberts wrote:
> Nagging is one way to accomplish change, but it's sure annoying. If you
> feel the feature is import, you know where to get the source. Give it a
> shot. Contribution of code is oh so much more valuable than a constant
> stream of "you
On Thu, 11 Nov 2010 04:34:07 +0200, bearophile
wrote:
So please kill automatic joining of adjacent strings in D with fire.
Yes please. I didn't even know this feature existed in D, but I was
recently bitten by a bug in a C++ program - also due to a missing comma in
an array of string li
"blue" "red"
I guess it exists because of a few use cases other than this one.
For this particular example, you are right i couldn't see it and i checked
two times!
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Brad Roberts:
> Nagging is one way to accomplish change, but it's sure annoying.
Right. I was a little too much nervous, sometimes I need to control myself a
little more :-)
> If you feel the feature is import, you know where to get the source. Give it
> a shot.
There is already a partial p
Yao G.:
> Stop blaming the compiler for your own carelessness.
If a simple common human error is avoidable at compile-time then it's the duty
of the compiler to avoid it. Blaming the programmer is just silly (and it's
against one of the main "philosophical" differences between C and D). I sugge
so wrote:
> > "blue" "red"
> I guess it exists because of a few use cases other than this one.
It's sometimes nice to be able to break up really long string literals, but it
looks like it's mostly a C holdover. In C it helps with some preprocessor
macros, but D doesn't have preprocessor macros
string someText = "I find it useful, and I like it. I like to break long
strings into smaller ones"
"and put each one in one line. I know that you can do that using one
single string, but"
"some syntax hightlighters don't like it that way.";
Now becomes:
string someText = "I find it
so:
> For 3 lines yes but how about a long file? Not everyone using vim!
There is very little D2 code around... and I don't think very large amounts of
concatenated strings in the source code are a good programming practice.
> What about this one?
>
> "red" "blue" => error
>
> "red"
> "blue"
On 11/10/2010 19:34, bearophile wrote:
> Do you seen anything wrong in this code? It compiles with no errors:
>
> enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
> static assert(data[4] == "yellow");
> void main() {}
>
>
> Yet that code asserts.
Wait, what? That's a static
On Thu, 11 Nov 2010 06:51:38 +0200, Rainer Deyke
wrote:
On 11/10/2010 19:34, bearophile wrote:
Do you seen anything wrong in this code? It compiles with no errors:
enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
static assert(data[4] == "yellow");
void main() {}
Yet th
Rainer Deyke wrote:
On 11/10/2010 19:34, bearophile wrote:
Do you seen anything wrong in this code? It compiles with no errors:
enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
static assert(data[4] == "yellow");
void main() {}
Yet that code asserts.
Wait, what? That's a
Don wrote:
> that's the only thing that is missing
Disagreed.
One of the main points of all languages is to emphasize ones aim,
espacially if there is a chance of misinterpretation because of the
language.
Example: there is only a tiny change in the characters from `31415' to `
3.1415'. Witho
On Wed, 10 Nov 2010 23:10:35 -0500
bearophile wrote:
> > For 3 lines yes but how about a long file? Not everyone using vim!
>
> There is very little D2 code around... and I don't think very large amounts
> of concatenated strings in the source code are a good programming practice.
Can't inse
Am 11.11.2010 11:16, schrieb spir:
On Wed, 10 Nov 2010 23:10:35 -0500
bearophile wrote:
> For 3 lines yes but how about a long file? Not everyone using vim!
There is very little D2 code around... and I don't think very large amounts of
concatenated strings in the source code are a good pr
Rainer Deyke:
> Wait, what? That's a static assert. How can it both assert and compile
> with no errors?
You are right, what I meant is that if you remove the assert the program
compiles with no errors (also note the number 5 that is different from 4
strings):
enum string[5] data = ["green",
Manfred_Nowak wrote:
Don wrote:
that's the only thing that is missing
Disagreed.
One of the main points of all languages is to emphasize ones aim,
espacially if there is a chance of misinterpretation because of the
language.
Example: there is only a tiny change in the characters from `31
On Wed, 10 Nov 2010 21:34:07 -0500, bearophile
wrote:
Do you seen anything wrong in this code? It compiles with no errors:
enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
static assert(data[4] == "yellow");
void main() {}
Yet that code asserts. it's an excellent example
Don wrote:
> But that fact isn't clear from the docs.
Thx for the clarification.
-manfred
On 2010-11-10 23:51:38 -0500, Rainer Deyke said:
As it turns out, the joining of adjacent strings is a critical feature.
Consider the following:
f("a" "b");
f("a" ~ "b");
These are /not/ equivalent. In the former cases, 'f' receives a string
literal as argument, which means that the strin
On Thu, 11 Nov 2010 11:18:19 +0100
dennis luehring wrote:
> Am 11.11.2010 11:16, schrieb spir:
> > On Wed, 10 Nov 2010 23:10:35 -0500
> > bearophile wrote:
> >
> >> > For 3 lines yes but how about a long file? Not everyone using vim!
> >>
> >> There is very little D2 code around... and I don'
Yao G. Wrote:
> On Wed, 10 Nov 2010 20:34:07 -0600, bearophile
> wrote:
>
> > Do you seen anything wrong in this code? It compiles with no errors:
> >
> > enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
> > static assert(data[4] == "yellow");
> > void main() {}
> >
> >
> >
Gary Whatmore:
> I fully agree with this. It's odd to see only few people opposing this,
> because the feature has no merit. If the language needs to be overly verbose
> in every turn, bearophile could go and use Java instead.
Is adding 1 char every time you use implicit joining of strings in y
On Thu, 11 Nov 2010 08:26:40 -0500, Gary Whatmore wrote:
Yao G. Wrote:
On Wed, 10 Nov 2010 20:34:07 -0600, bearophile
wrote:
> Do you seen anything wrong in this code? It compiles with no errors:
>
> enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
> static assert(data[
Steven Schveighoffer Wrote:
> On Thu, 11 Nov 2010 08:26:40 -0500, Gary Whatmore wrote:
> > Multiline strings have traditionally required stupid hacks. D might be
> > the only string oriented language with so many useful string literals.
> > Very useful in string processing.
>
> In this case,
Am 11.11.2010 14:28, schrieb spir:
On Thu, 11 Nov 2010 11:18:19 +0100
dennis luehring wrote:
Am 11.11.2010 11:16, schrieb spir:
> On Wed, 10 Nov 2010 23:10:35 -0500
> bearophile wrote:
>
>> > For 3 lines yes but how about a long file? Not everyone using vim!
>>
>> There is ver
On 11/11/10 4:36 AM, Don wrote:
Manfred_Nowak wrote:
Don wrote:
that's the only thing that is missing
Disagreed.
One of the main points of all languages is to emphasize ones aim,
espacially if there is a chance of misinterpretation because of the
language.
Example: there is only a tiny cha
On Thu, 11 Nov 2010 10:03:58 -0500, Andrei Alexandrescu
wrote:
On 11/11/10 4:36 AM, Don wrote:
Manfred_Nowak wrote:
Don wrote:
that's the only thing that is missing
Disagreed.
One of the main points of all languages is to emphasize ones aim,
espacially if there is a chance of misinterp
+1 on this.
While implicit joining can certainly be useful in C in some cases, D has
the ~ operator for such cases.
Since compile-time primitives are guaranteed to be folded anyway (IIRC),
I can imagine no situation where the benefits of banning implicit
joining (reducing the chance for bugs
On 11/11/2010 06:06, Michel Fortin wrote:
> On 2010-11-10 23:51:38 -0500, Rainer Deyke said:
>
>> As it turns out, the joining of adjacent strings is a critical feature.
>> Consider the following:
>> f("a" "b");
>> f("a" ~ "b");
>> These are /not/ equivalent. In the former cases, 'f' receiv
On 2010-11-11 15:05:08 -0500, Rainer Deyke said:
On 11/11/2010 06:06, Michel Fortin wrote:
On 2010-11-10 23:51:38 -0500, Rainer Deyke said:
As it turns out, the joining of adjacent strings is a critical feature.
Consider the following:
f("a" "b");
f("a" ~ "b");
These are /not/ equivalent.
Rainer Deyke Wrote:
>
> As it turns out, the joining of adjacent strings is a critical feature.
> Consider the following:
> f("a" "b");
> f("a" ~ "b");
> These are /not/ equivalent.
I would hope that the const folding mechanism would combine these at
compile-time. There's effectively no di
Now this discussion seems settled enough, so I may summarize its results a
little (please fix this list if you see an error):
- Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.
- Don has not said how much he likes the idea, but he has
On 11/11/10 3:33 PM, bearophile wrote:
Now this discussion seems settled enough, so I may summarize its results a
little (please fix this list if you see an error):
- Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.
- Don has not sai
Freshly added to the normal-priority queue!
Thank goodness.
On Thu, Nov 11, 2010 at 6:11 PM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
> On 11/11/10 3:33 PM, bearophile wrote:
>
>> Now this discussion seems settled enough, so I may summarize its results a
>> little (please fix t
Andrei:
> Let me ask a related question: if there were a priority list of things
> that Walter should be busy with, where would this feature be on that list?
I don't know, I think you and Walter are able to judge the relative priorities
of things. In Bugzilla I have about twenty small/tiny brea
Andrei Alexandrescu wrote:
Let me ask a related question: if there were a priority list of things
that Walter should be busy with, where would this feature be on that list?
For once, I agree with Bearophile. The adjacent string concatenation was a very
very early feature, and the ~ completely
> For once, I agree with Bearophile. The adjacent string concatenation was a
> very
> very early feature, and the ~ completely supplants it. While I don't think it
> causes many problems, it's a pointless redundancy and should be removed.
Agreed; it seems to be a minor change, and the issue of
Gary Whatmore wrote:
Multiline strings have traditionally required stupid hacks.
Yeah, I always hated that. Why couldn't I just insert some multiline text and
just put it in quotes? Naw, I have to laboriously quote each line separately.
Ridiculous.
On 11/11/10 5:59 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Let me ask a related question: if there were a priority list of things
that Walter should be busy with, where would this feature be on that
list?
For once, I agree with Bearophile. The adjacent string concatenation was
a very
On 11/11/2010 13:37, Sean Kelly wrote:
> Rainer Deyke Wrote:
>>
>> As it turns out, the joining of adjacent strings is a critical
>> feature. Consider the following: f("a" "b"); f("a" ~ "b"); These
>> are /not/ equivalent.
>
> I would hope that the const folding mechanism would combine these at
>
bearophile Wrote:
> - Andrei Alexandrescu has said this idea doesn't harm but he sees not much
> evidence this is a problem in C/C++.
Well, scope classes aren't more harmful than this.
On 11/12/10 12:03 AM, Kagamin wrote:
bearophile Wrote:
- Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.
Well, scope classes aren't more harmful than this.
I think there's really no comparison there.
Andrei
Let me ask a related question: if there were a priority list of things
that Walter should be busy with, where would this feature be on that list?
i think bearophil just tries to install an community-decision-process
and the first post of this thread seems to feel right, all other
dicussions en
Am 12.11.2010 00:33, schrieb bearophile:
Now this discussion seems settled enough, so I may summarize its results a
little (please fix this list if you see an error):
- Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.
- Don has not s
Andrei Alexandrescu wrote:
On 11/11/10 5:59 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Let me ask a related question: if there were a priority list of things
that Walter should be busy with, where would this feature be on that
list?
For once, I agree with Bearophile. The adjacent str
On 11/12/10 1:06 AM, Don wrote:
Andrei Alexandrescu wrote:
On 11/11/10 5:59 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Let me ask a related question: if there were a priority list of things
that Walter should be busy with, where would this feature be on that
list?
For once, I agree
On Thu, 11 Nov 2010 19:11:54 -0500, Andrei Alexandrescu
wrote:
On 11/11/10 3:33 PM, bearophile wrote:
Now this discussion seems settled enough, so I may summarize its
results a little (please fix this list if you see an error):
- Andrei Alexandrescu has said this idea doesn't harm but he
On Fri, 12 Nov 2010 04:53:23 -0500, Andrei Alexandrescu
wrote:
On 11/12/10 1:06 AM, Don wrote:
Andrei Alexandrescu wrote:
On 11/11/10 5:59 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Let me ask a related question: if there were a priority list of
things
that Walter should be bus
On 11/12/10 4:41 AM, Steven Schveighoffer wrote:
On Fri, 12 Nov 2010 04:53:23 -0500, Andrei Alexandrescu
wrote:
On 11/12/10 1:06 AM, Don wrote:
Andrei Alexandrescu wrote:
On 11/11/10 5:59 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Let me ask a related question: if there were a pri
Andrei:
> will do more work than before. We must avoid that.
I have added a note at the bottom of the relative bug report.
Bye,
bearophile
On 12/11/2010 09:53, Andrei Alexandrescu wrote:
Well put me on board then. Walter, please don't forget to tweak the
associativity rules: var ~ " literal " ~ " literal " concatenates
literals first.
You mean make ~ right-associative? I think this'll break more code than
it fixes.
But implem
Stewart Gordon:
> You mean make ~ right-associative? I think this'll break more code than
> it fixes.
>
> But implementing a compiler optimisation so that var ~ ctc ~ ctc is
> processed as var ~ (ctc ~ ctc), _in those cases where they're
> equivalent_, would be sensible.
>
> ctc = compile-ti
Stewart Gordon wrote:
> On 12/11/2010 09:53, Andrei Alexandrescu wrote:
>
>> Well put me on board then. Walter, please don't forget to tweak the
>> associativity rules: var ~ " literal " ~ " literal " concatenates
>> literals first.
>
> You mean make ~ right-associative? I think this'll break mo
Stewart Gordon wrote:
On 12/11/2010 09:53, Andrei Alexandrescu wrote:
Well put me on board then. Walter, please don't forget to tweak the
associativity rules: var ~ " literal " ~ " literal " concatenates
literals first.
You mean make ~ right-associative? I think this'll break more code than
On 20/11/2010 05:31, Walter Bright wrote:
Stewart Gordon wrote:
On 12/11/2010 09:53, Andrei Alexandrescu wrote:
Well put me on board then. Walter, please don't forget to tweak the
associativity rules: var ~ " literal " ~ " literal " concatenates
literals first.
You mean make ~ right-associat
On 11/29/10 3:38 PM, Bruno Medeiros wrote:
On 20/11/2010 05:31, Walter Bright wrote:
Stewart Gordon wrote:
On 12/11/2010 09:53, Andrei Alexandrescu wrote:
Well put me on board then. Walter, please don't forget to tweak the
associativity rules: var ~ " literal " ~ " literal " concatenates
lite
On 11/11/2010 23:33, bearophile wrote:
Now this discussion seems settled enough, so I may summarize its results a
little (please fix this list if you see an error):
- Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.
- Don has not sai
60 matches
Mail list logo
