Mike James Wrote:
> case 1 to 5:
Can't resist... :)
case foreach (n; 1..6):
Ali
If the default behavior for dout.writefln is to print bool values as the "true"
and "false" strings, then the opposite should be available and arguably be the
default:
// "true" and "false" should be acceptable inputs:
bool b;
din.readf(&b);
Am I wrong?
Thanks,
Ali
P.S. There hasn't bee
language_fan Wrote:
> One way to teach languages with both high and low level concepts is to
> start bottom-up. Surely the high level concepts are usually built from
> atomic low level artifacts.
I agree. I am writing an online D tutorial that targets the novice programmer,
where the concepts
You may be aware of the problems related to the consistency of the two separate
letter 'I's in the Turkish alphabet (and the alphabets that are based on the
Turkish alphabet).
Lowercase and uppercase versions of the two are consistent in whether they have
a dot or not:
http://en.wikipedia.or
Rainer Deyke Wrote:
> This appears to be a library issue to me.
I started to see this at a more fundamental level. The Unicode letter I
(dotless capital i) has two possible lowercases and letter i has two possible
uppercases. The chain of some historical events appears to have produced a
cripp
Walter Bright Wrote:
> with details of the Turkish language because I
> have no idea how it works.
It is a very interesting story. The Turkish 'i's have caused lots of trouble,
even hardcoded conditionals in at least the early Java libraries that checked
whether the locale was Turkish.
Even t
Is there a common(-ish) naming style for D?
- camel case or underscores within words of names?
- type names begin with capital?
- underscore before or after member names?
- enum values lowercase?
- constant names?
- etc.? :)
Do you have a document that you would like to share?
Thank you,
Al
Thank you!
Jarrett Billingsley Wrote:
> Many people don't indicate class members with any kind of decoration
I noticed that too. :)
The justification that I've come up with is that, we need the decoration in
e.g. C++, because the member declaration is not visible in the implementation
file, so
Stewart Gordon Wrote:
> I is the uppercase form of ı.
> Ä° is the uppercase form of i.
>
> http://www.unicode.org/Public/UNIDATA/UnicodeData.txt
> lists them as
> 0049;LATIN CAPITAL LETTER I;Lu;0;L;N0069;
> 0069;LATIN SMALL LETTER I;Ll;0;L;N;;;0049;;0049
> 0130;LATIN CAPITAL LETTER I
I use first person when I make side notes like
- "I've chosen to do it this way, because ..."
- "I will deviate from my decision of not using any feature that is not yet
explained ..."
- "Because of a bug in Phobos, I had to use the .dup property with the format
strings in the following sample
AJ Wrote:
> Why not eliminate the requirement for semicolon statement terminators
> (unless there are multiple statements per line)? Less typing is "more"!
A number of times in this thread, you claimed that you were not proposing
anything but merely asking "Why?".
You may have very well inten
Don Wrote:
> The floating point types have a property called ".min", but unlike the
> integer ".min", it's not the minimum!
That bothered me too when I was writing about it before; I felt embarrassed
when explaining that it was not actually the minimum. :)
Ali
I haven't started reading Andrei's chapter on arrays yet. I hope I won't find
out that the following behavior is expected. :)
import std.cstream;
void modify(int[] a)
{
a[0] = 1;
a ~= 2;
dout.writefln("During: ", a);
}
void main()
{
int[] a = [ 0 ];
dout.writefln("Before:
Thanks for all the responses.
And yes, I know that 'ref' is what works for me here. I am trying to figure out
whether I should develop a guideline like "always pass arrays with 'ref', or
you may face surprises."
I understand it very well now and was able to figure out a way to cause some
bugs.
Andrei Alexandrescu Wrote:
> Ali Cehreli wrote:
> > I don't think that this is easy to explain to a learner; and I think that
> > is a good indicator that there is a problem with these semantics.
>
> The ball is in your court to define better semantics.
>
> And
gzp Wrote:
> I think problem is that, dynamic arrays and slices are NOT the same.
I agree with most of what you wrote, but I can't see that in the current
implementation.
> They have a common subset of interfaces (length, at, slice(maybe)), but
> they are just different. An array owns it's el
Andrei Alexandrescu Wrote:
> My perception following the discussion around typedef is that we should
> eliminate it. What we offer is "alias", which is a generalization of C's
> "typedef", and the change of name is justified by the fact that "alias"
> defines aliases for more entities than just
Bartosz Milewski Wrote:
> I read Andrei's chapter on arrays and there's one thing that concerns me.
I tried to voice the same concern earlier, but my voice is not loud yet. ;)
> When a slice is extended, the decision to re-allocate, and therefore to cut
> its connection to other slices, is non-d
Bartosz Milewski Wrote:
> > int[] a = [0];
> > auto b = a;
> > a ~= 1;
> > b ~= 2;
> > What is a[1]?
> >
> > Is this considered "stomping" and requiring a re-allocation?
>
> Can this question be answered without the recourse to implementation, and the
> MRU cache in particular?
>
> I thought a
dsimcha Wrote:
> == Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
> > > int[] a = [0];
> > > auto b = a;
> > > a ~= 1;
> > > b ~= 2;
> > > What is a[1]?
> > >
> > > Is this considered "stomping" and requiring a re-allocation?
> > Can this question be answered without the reco
Lars T. Kyllingstad Wrote:
> The decision to dump the built-in complex and imaginary types in favour
> of std.complex.Complex was made a long time ago, but nothing has
> happened yet. So I have a few questions:
>
> 1. Is this still planned for D2?
>
> 2. In that case, when will it happen?
>
>
21 matches
Mail list logo
