On Monday, 15 October 2018 at 19:56:22 UTC, Nicholas Wilson wrote:
import std.file : readText;
import std.uni : byCodePoint, byGrapheme;
// or import std.utf : byCodeUnit, byChar /*utf8*/, byWchar
/*utf16*/, byDchar /*utf32*/, byUTF /*utf8(?)*/;
string a = readText("foo");
foreach(cp;
On Monday, 15 October 2018 at 17:55:34 UTC, Dukc wrote:
This is done automatically for character arrays, which includes
strings. wchar arrays wil iterate by UTF-16, and dchar arrays
by UTF-32. If you have a byte/ubyte array you know to be
unicode-encoded, convert it to char[] to iterate by
Is there a standardised way of reading over buffered binary
streams (at least strings, files, and sockets) where you can
layer a decoder on top, so you get a character stream you can
read one Unicode char at a time? Initially UTF-8, but later also
other encodings. I see that std.stream was
On Monday, 15 October 2018 at 22:49:31 UTC, Nicholas Wilson wrote:
Oh, sorry I missed that. Take a look at
https://github.com/schveiguy/iopipe
Great, thanks.
Excuse my ignorance, but from looking at the documentation on
std.range and a quick skim of the guides mentioned there near the
top, I can't see what the simple way is of creating an
InputRange!(ubyte) from strings, files etc. I would have expected
to find something in the DLang Tour about
On Thursday, 8 November 2018 at 14:38:37 UTC, Paul Backus wrote:
You can iterate through a file one ubyte at a time using
`byChunk` and `joiner`:
auto r1 = stdin.byChunk(1024).joiner;
assert(is(typeof(r1.front) == ubyte));
You can iterate through a string one ubyte at a time using
According to the std.utf documentation,
decode will only work with strings and random access ranges of
code units with length and slicing, whereas decodeFront will
work with any input range of code units.
However, I can't seem to get such a usage to compile: the
following code
import
On Friday, 9 November 2018 at 10:26:46 UTC, Dennis wrote:
On Friday, 9 November 2018 at 09:47:32 UTC, Vinay Sajip wrote:
std.utf.decodeFront(Flag useReplacementDchar =
No.useReplacementDchar, S)(ref S str) if (isInputRange!S &&
isSomeChar!(ElementType!S))
This is the overload you want, let's
On Friday, 9 November 2018 at 11:24:42 UTC, Jonathan M Davis
wrote:
decode and decodeFront are for converting a UTF code unit to a
Unicode code point. So, you're taking UTF-8 code unit (char),
UTF-16 code unit (wchar), or a UTF-32 code unit (dchar) and
decoding it. In the case of UTF-32,
On Thursday, 8 November 2018 at 16:41:50 UTC, Steven
Schveighoffer wrote:
I did this in a run.dlang.org playground:
pragma(msg, ElementType!(typeof(b)));
pragma(msg, ElementType!(typeof(d)));
I get:
immutable(ubyte)
ubyte
Which means they aren't the same type, and they don't define
the same
On Thursday, 8 November 2018 at 14:38:37 UTC, Paul Backus wrote:
To pass these ranges around using the `InputRange` interface,
use `inputRangeObject` to wrap them:
InputRange!ubyte r3 = inputRangeObject(r1);
InputRange!(immutable(ubyte)) r4 = inputRangeObject(r2);
I did a bit more
This code should IMO give at least a warning, but it doesn't:
abstract class A {
int kind;
}
class B : A {
int kind;
this(int k) {
kind = k;
}
}
In my actual code, the declaration of field "kind" in B was left
in accidentally. Surprisingly, however, no warning was
On Friday, 16 November 2018 at 17:08:00 UTC, Basile B. wrote:
I agree that this is almost a case of shadowing but i don't
know the exact rationale for allowing this.
I'm not saying it shouldn't be allowed - just that the compiler
could warn you about what might very well be a mistake (as it
On Friday, 16 November 2018 at 17:35:13 UTC, Basile B. wrote:
D is not a compiler that warns much. You can still open an
issue asking for this (and the warning must be easy to add at
first glance), but the policy applied to warnings is "compilers
warnings are a sign of design flaws so instead
On Friday, 16 November 2018 at 19:12:42 UTC, Dennis wrote:
If something is definitively wrong, then it should be an error.
If it's not definitively wrong, then the compiler shouldn't say
anything about it, and it should be left up to a linter tool of
some kind like dcd."
Are arrays and objects part of a unified type system?
Specifically, if I do
void foo(Object x) {
if (typeid(x) == typeid(Object[])) {
auto a = cast(Object[]) x;
}
}
I get a compilation error:
onlineapp.d(3): Error: cannot cast expression x of type
object.Object to Object[]
On Thursday, 17 October 2019 at 12:40:33 UTC, Adam D. Ruppe wrote:
On Thursday, 17 October 2019 at 12:19:03 UTC, Vinay Sajip wrote:
Are arrays and objects part of a unified type system?
No, they are separate. You can define a class that contains an
array, but it doesn't work like that
The following program won't compile if I uncomment the if
statement:
void main()
{
Variant v = complex(1.0, 1.0);
//if (v.peek!(Complex)) {
//writeln("Complex");
//}
writeln(v);
}
I get the same error with v.peek!(complex), which is:
Error: template instance
On Saturday, 22 February 2020 at 18:32:06 UTC, nullptr wrote:
The type in v isn't Complex, it's Complex!double.
Ah, great. Thanks! Missed that.
19 matches
Mail list logo
