On Friday, 10 September 2021 at 18:05:30 UTC, Ron Tarrant wrote:
I'm asking all this because I thought it would be a good idea
to have an analog copy handy
I second this; when Ali thinks the one printed on dead-tree-media
is up-to date I'll snap a copy of it too; this is one of those
books
On Friday, 10 September 2021 at 18:05:30 UTC, Ron Tarrant wrote:
On another note, I've been thinking about rewriting the GtkD
Coding blog as a book ...
interesting :)
On Friday, 10 September 2021 at 14:21:12 UTC, Ali Çehreli wrote:
The following is a list of different versions of the book.
1) The git clone on my computer is the newest, which I may sit
on for weeks for minor corrections. (These corrections are
recommended by most of you; thank you!) So,
On Monday, 6 September 2021 at 01:18:20 UTC, Ali Çehreli wrote:
That's because I've been using Thunderbird for mail and news
for a long time now and unfortunately it is impossible to
convince Thunderbird to add the necessary header field.
(Vladimir has a recommendation where I can run a simply
On Sunday, 5 September 2021 at 17:55:09 UTC, Steven Schveighoffer
wrote:
-Steve
Slightly off-topic but ... while-we-are-the-subject:
I usually post with markdown enabled and enclose code within ```d
Sometimes, I notice that replies to my posts came without
markdown, and until now, I
On Saturday, 4 September 2021 at 23:57:09 UTC, jfondren wrote:
You're returning a copy of a slice, so if this compiled nothing
useful would happen anyway. This works if `whatever()` returns
`ref dstring` instead, with no other changes. Search
https://dlang.org/spec/function.html for 'lvalue'
```d
public class cSomething {
private:
dstring pstrWhatever = null;
public:
@safe dstring whatever() { return pstrWhatever; }
@safe void whatever(const dstring lstrWhatever) { pstrWhatever
= lstrWhatever; }
}
void main() {
cSomething lobjSomething = new cSomething();
On Tuesday, 31 August 2021 at 07:40:10 UTC, bauss wrote:
You might be interested in https://yuraiweb.org/
Even though it's a work in progress then you should be able to
get by just fine with the basics for now.
Thanks for the tip bauss :) !
I am exploring it right now. Main problem is the
On Tuesday, 31 August 2021 at 14:06:32 UTC, Steven Schveighoffer
wrote:
The generation of code to output the page depends on the diet
file format (i.e. code islands are designated by the leading
`-`).
However, vibe-d does not require using the diet template system.
Does that means I can
Regarding vibe.d I think I'll give it a try (maybe placing it
behind nginx at first) since I do really got a good
first-impression ... kudos to the developers/maintainers :)
I like the idea of having D at my disposal within a web page,
actually, it is a terrific feature to say the least.
On Monday, 30 August 2021 at 06:52:16 UTC, Daniel Kozak wrote:
Maybe add a new group to the forum for vibed and redirect
https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed there
At the *very least* they should remove the link on their home
page pointing to the useless forum.
On Monday, 30 August 2021 at 10:37:38 UTC, Steven Schveighoffer
wrote:
It used to be moderated somewhat, but I think they gave up (99%
of the messages were porn or spam).
Why don't they shut down the forum instead ?
It makes a terrible impression for newcomers -something akin to:
naaah,
On Monday, 30 August 2021 at 06:19:02 UTC, bauss wrote:
Just use these forums as pretty much the same people are here
that are in the vibe.d community.
OK. Thanks :)
https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/
I've been reading vibe.d tour and some documentation today to get
some first impressions. https://vibed.org/community pointed to
the link above ... but it seems it is full of crap.
On Sunday, 8 August 2021 at 05:07:17 UTC, jfondren wrote:
On Sunday, 8 August 2021 at 04:51:48 UTC, someone wrote:
On Sunday, 8 August 2021 at 04:30:12 UTC, rikki cattermole
wrote:
So a field that will automatically be resolved to as part of
the behavior of generated toString methods.
No. A
On Sunday, 8 August 2021 at 04:30:12 UTC, rikki cattermole wrote:
So a field that will automatically be resolved to as part of
the behavior of generated toString methods.
No. A default property can be another object altogether. The best
use case I can think of is a default collection for a
On Sunday, 8 August 2021 at 00:57:47 UTC, Paul Backus wrote:
On Sunday, 8 August 2021 at 00:52:43 UTC, someone wrote:
Now that I am aware of Walter's stance on alias this:
"alias this has turned out to be a mistake" @
https://news.ycombinator.com/item?id=28029184
... would you, I mean the
Now that I am aware of Walter's stance on alias this:
"alias this has turned out to be a mistake" @
https://news.ycombinator.com/item?id=28029184
... would you, I mean the community, think is it a good idea to
file a DIP to eventually get a new attribute to unambiguously
label a class'
On Friday, 6 August 2021 at 04:57:02 UTC, Ali Çehreli wrote:
May I humbly suggest names like Location instead of
structureLocation to make refactoring even more
straightforward. ;)
just renamed everything like following:
- sWhatever for structures
- iWhatever for interfaces
- cWhatever for
On Friday, 6 August 2021 at 04:57:02 UTC, Ali Çehreli wrote:
On 8/5/21 5:11 PM, someone wrote:
> Although I have very little experience with D, I second this:
> refactoring, even huge refactors, proved to be far more
straightforward
> than I expected.
May I humbly suggest names like Location
On Thursday, 5 August 2021 at 20:50:38 UTC, Steven Schveighoffer
wrote:
I mean eventually AAs that are reasonably available at compile
time, even though the structure is determined by the runtime,
should be available at compile time. This allows them to be as
usable with static immutable as
On Thursday, 5 August 2021 at 17:12:13 UTC, H. S. Teoh wrote:
[...]
I'd say if the performance hit isn't noticeably bad right now,
don't worry too much about it. You can always replace it later.
One thing I really like about D is how easily refactorable D
code tends to be. If you structure
On Thursday, 5 August 2021 at 16:24:21 UTC, jfondren wrote:
On Thursday, 5 August 2021 at 16:06:58 UTC, someone wrote:
So if we are talking AA-arrays at compile-time only there
should be nothing wrong with the following code ... right ?
...
private enum pudtLocations = [
r"BUE"d :
On Thursday, 5 August 2021 at 15:23:24 UTC, Ali Çehreli wrote:
As I understand it, @property is discouraged by the community.
That's what I say here:
http://ddili.org/ders/d.en/property.html#ix_property.@property
I knew I have read it somewhere ... thanks for the clarification
Ali !
On Thursday, 5 August 2021 at 15:26:33 UTC, H. S. Teoh wrote:
On Thu, Aug 05, 2021 at 03:09:13PM +, someone via
Digitalmars-d-learn wrote:
On Thursday, 5 August 2021 at 10:28:00 UTC, Steven
Schveighoffer wrote:
> H.S. Teoh, I know you know better than this ;) None of this
> is nec
On Thursday, 5 August 2021 at 10:28:00 UTC, Steven Schveighoffer
wrote:
H.S. Teoh, I know you know better than this ;) None of this is
necessary, you just need `rtValue` for both runtime and CTFE
(and compile time parameters)!
Now, the original question is about *associative arrays*, which
On Thursday, 5 August 2021 at 03:20:17 UTC, H. S. Teoh wrote:
On Thu, Aug 05, 2021 at 01:39:42AM +, someone via
Digitalmars-d-learn wrote: [...]
What happens in the following case ?
public immutable enum gudtLocations = [
r"BUE"d : structureLocation(r"arg"d, r"
On Thursday, 5 August 2021 at 02:43:09 UTC, Steven Schveighoffer
wrote:
The main difference between enums and static immutable is that
the latter has an address at runtime.
This. Gotcha.
So the answer is, depends on what you are going to do with the
data. There are use cases for both. If you
On Thursday, 5 August 2021 at 02:06:13 UTC, Steven Schveighoffer
wrote:
On 8/4/21 9:14 PM, H. S. Teoh wrote:
Unless you have a specific reason to, avoid using `enum` with
string and
array literals, because they will trigger a memory allocation
*at every
single reference to them*, which is
On Thursday, 5 August 2021 at 01:47:36 UTC, Alexandru Ermicioi
wrote:
On Wednesday, 4 August 2021 at 22:28:53 UTC, someone wrote:
Is that what you mean ?
Not really. I was assuming you were talking about @property
methods, and if so you could declare such cases:
```
interface
On Thursday, 5 August 2021 at 01:14:26 UTC, H. S. Teoh wrote:
1) If the constant is a POD (int, float, etc.), use:
enum myValue = ...;
crystal-clear.
2) If the constant is a string or some other array:
static immutable string myString = "...";
crystal-clear.
2) If the
What are the pros/cons of the following approaches ?
```d
/// first day with D:
public const dstring gstrWhatever = "...";
/// next:
public immutable dstring gstrWhatever = "...";
/// next:
public immutable dstring gstrWhatever;
this() {
gstrWhatever = "...";
}
/// next
On Wednesday, 4 August 2021 at 22:22:29 UTC, Adam D Ruppe wrote:
On Wednesday, 4 August 2021 at 22:01:21 UTC, someone wrote:
No. I didn't know it ever existed :(
It is good to look at the source code implementations of some
of those things too. Most are built out of language features
and
On Wednesday, 4 August 2021 at 16:41:04 UTC, Alexandru Ermicioi
wrote:
Since you're using classes consider just declaring an interface
that denotes that implementor has this field, it would be much
easier to check for it, and easier for compiler since it avoids
compile time magic.
I am not
On Wednesday, 4 August 2021 at 16:41:04 UTC, Alexandru Ermicioi
wrote:
On Wednesday, 4 August 2021 at 15:08:24 UTC, someone wrote:
However, __traits(hasMember, ...) checks for the existence of
anything labeled lstrCurrencyID within the class (eg:
unrelated variables with same name; not gonna
On Wednesday, 4 August 2021 at 20:13:53 UTC, Steven Schveighoffer
wrote:
On 8/4/21 11:08 AM, someone wrote:
Have you looked at
[std.traits](https://dlang.org/phobos/std_traits.html) at all?
It does a lot of stuff, including giving you parameter names
and types.
No. I didn't know it ever
I have the following chunk of code that needs to conditionally
instantiate existing classes (at compilation time) named
classTickerCustom{ExchangeID} with one or ... two parameters (if
any); eg:
```d
/// securities trading on exchange primary currency; eg: USD
... = new
On Sunday, 25 July 2021 at 17:45:18 UTC, Adam D Ruppe wrote:
On Sunday, 25 July 2021 at 17:29:46 UTC, someone wrote:
What is the proper syntax to use manifest-constants with
associative arrays then ? The one you showed me ?
You have the right syntax for that. What I'm saying is you
might not
On Sunday, 25 July 2021 at 07:22:54 UTC, jfondren wrote:
On Sunday, 25 July 2021 at 05:10:32 UTC, someone wrote:
/// implementation: however, would it be possible to
dynamically‐load the following enums from a file at
compilation‐time ?
public immutable enum structureLocations = [
r"BUE"d
On Sunday, 25 July 2021 at 10:30:47 UTC, Adam D Ruppe wrote:
On Sunday, 25 July 2021 at 05:10:32 UTC, someone wrote:
As you can see in the following code I cannot avoid to type
the public immutable enum structureLocations = [
r"BUE"d : typeLocation(r"arg"d, r"Buenos Aires"d, r"ART"d),
As you can see in the following code I cannot avoid to type the
IDs twice in the structureExchanges enum:
```d
public struct structureExchange { /// solely‐intended to help
build code at compilation‐time; for client‐code classExchanges
should be used instead
public typeLocation location;
On Saturday, 24 July 2021 at 01:44:11 UTC, Adam D Ruppe wrote:
On Saturday, 24 July 2021 at 01:29:26 UTC, someone wrote:
Suppose I have a module with the following:
static if(is(classTickerCustomNYSE))
// it was a valid type
else
// it was not a valid type
can use that to test. you
Suppose I have a module with the following:
```d
public class classTickerCustomNYSE : classTickerCommon { ... }
public class classTickerCustomNASDAQ : classTickerCommon { ... }
```
... and given that I also have the following in the same module:
```d
public enum structureExchanges = [
On Thursday, 22 July 2021 at 08:16:43 UTC, Patrick Schluter wrote:
What an unreadable mess. Sorry.
Indeed LoL !!!
I would have done something like that:
```d
mixin(format!
`case r"%1$s"d :
classTickerCustom%1$s lobjTicker%1$s = new
classTickerCustom%1$s (lstrSymbolID);
On Thursday, 22 July 2021 at 05:57:02 UTC, jfondren wrote:
Each individual string has to compile on its own. You'll have
to concatenate strings and then mixin them.
I forgot about that !
The following code chunk compiles perfectly:
```d
labelSwitch: switch (lstrExchangeID) {
static foreach (sstrExchangeID; gstrExchangeIDs) {
mixin(r"case r"d, `"`, sstrExchangeID, `"`, r"d : "d);
mixin(r"classTickerCustom"d, sstrExchangeID, r" lobjTicker"d,
sstrExchangeID, r" = new
On Monday, 19 July 2021 at 03:52:51 UTC, SealabJaster wrote:
On Monday, 19 July 2021 at 03:51:02 UTC, SealabJaster wrote:
...
There's also Ali Cehreli's book, which is excellent.
I stepped into D alongside Andrei and Ali's books. Ali's one I
was aware it existed but I didn't start to read
On Monday, 19 July 2021 at 03:05:24 UTC, Paul Backus wrote:
On Monday, 19 July 2021 at 01:45:27 UTC, SealabJaster wrote:
On Monday, 19 July 2021 at 01:26:25 UTC, someone wrote:
...
Not 100% sure this works in all cases, but this version
doesn't need the caller to make use of a mixin:
On Monday, 19 July 2021 at 01:45:27 UTC, SealabJaster wrote:
On Monday, 19 July 2021 at 01:26:25 UTC, someone wrote:
...
Not 100% sure this works in all cases, but this version doesn't
need the caller to make use of a mixin:
https://run.dlang.io/is/3jLxLz
http://dlang.org/traits.html ...
On Monday, 19 July 2021 at 00:52:39 UTC, Paul Backus wrote:
The closest you can get is to use a string mixin:
```d
enum debugWriteln(string expression) =
`writeln(q"(` ~ expression ~ `)", " = ", ` ~ expression ~
`);`;
// Usage:
mixin(debugWriteln!"lobjExchanges.count");
```
clever :)
I know the answer for this will be a resoundingly no, but, anyway
...
I have, more-or-less, the following function:
```d
public void debugwriteln(typeValue)(
const dstring lstrTag,
const typeValue lstrValue
) {
writeln(console.colorizeYellow(r"debugging"d), r" → "d,
lstrTag,
On Sunday, 18 July 2021 at 11:04:55 UTC, Adam D Ruppe wrote:
On Sunday, 18 July 2021 at 03:52:30 UTC, someone wrote:
That being said, one of the things that I felt in love with
when I was first exposed to was OOP; with all its pros and
cons.
Yeah I like a lot about OOP and D's implementation
On Sunday, 18 July 2021 at 11:03:24 UTC, Adam D Ruppe wrote:
Fun fact there: any child implementations do NOT need to
specify the attribute there; the compiler will copy it from the
interface for you.
I suppose these are the day-to-day minor details you can rely on
to avoid typing a lot of
On Sunday, 18 July 2021 at 01:49:11 UTC, Brian Tiffin wrote:
It's our best hope. Self taught programming is scary. School
taught programming is scary. Corporate taught programming is
scary. *Practice makes perfect? No, practice makes permanent.*
The sanest path forward for the profession
On Saturday, 17 July 2021 at 21:01:00 UTC, Adam Ruppe wrote:
From the interface perspective: are these signatures identical
or not ?
No, they are very different.
This helped me solve an issue that I carried since a few days ago:
I have an interface with function members *not* being
On Saturday, 17 July 2021 at 22:48:00 UTC, Adam D Ruppe wrote:
On Saturday, 17 July 2021 at 22:43:15 UTC, someone wrote:
So the lesson learned is that interfaces can also mandate
member function's parameter attributes then ... right ?
A subclass must accept anything the parent class can, but
On Saturday, 17 July 2021 at 21:46:38 UTC, Jack Applegame wrote:
Just remove `ref`, because in D clasess themselves are
references.
All refs are goners now; thanks :) !
On Saturday, 17 July 2021 at 21:01:00 UTC, Adam Ruppe wrote:
No, they are very different.
So the lesson learned is that interfaces can also mandate member
function's parameter attributes then ... right ?
But you also don't gain much from const here and that ref is
probably actively
On Saturday, 17 July 2021 at 21:02:38 UTC, Adam Ruppe wrote:
Why are you using ref here at all?
Muscle memory I suppose; objects need to be passed by reference,
these are the things I'll need to be re-wired to in D.
You probably shouldn't be using it. But if it is legitimately
needed you
The following gives me a compiler error when I add the second
parameter:
is not an lvalue and cannot be modified
```d
public bool add(
ref classTickerID robjTickerID,
ref classExchanges robjExchanges = null /// needing this
optional
) {
}
```
If I take out the null then the
```d
public interface intefaceWhatever {
public bool doSomething(
dstring lstrID,
classX robjX
);
}
```
vs
```d
public interface intefaceWhatever {
public bool doSomething(
const dstring lstrID,
ref classX robjX
);
}
```
From the interface
On Wednesday, 14 July 2021 at 23:44:18 UTC, jfondren wrote:
On Wednesday, 14 July 2021 at 22:59:38 UTC, someone wrote:
[...]
so, these lines:
```d
stringUGC32 lugcSequence3 = stringUGC32(cast(char) 'x');
stringUGC32 lugcSequence4 = stringUGC32(1);
```
which call stringUGC32, an
On Wednesday, 14 July 2021 at 19:00:08 UTC, jfondren wrote:
On Wednesday, 14 July 2021 at 18:04:44 UTC, someone wrote:
On Wednesday, 14 July 2021 at 06:28:37 UTC, jfondren wrote:
alternate 1:
- pull tests out into a named enum template, like std.traits
- always static assert enum, rather than
On Wednesday, 14 July 2021 at 06:28:37 UTC, jfondren wrote:
alternate 1:
- pull tests out into a named enum template, like std.traits
- always static assert enum, rather than conditionally
asserting false
- always have the rest of the code
```d
enum isString(T) = is(T == string) || is(T ==
On Wednesday, 14 July 2021 at 02:42:21 UTC, Paul Backus wrote:
Weirdly, adding a dummy `ResultType` declaration to the `else`
branch makes the assert message show up:
My code is like following:
```d
public struct gudtUGC(typeStringUTF) {
static if (! (is (typeStringUTF == string) || is
The following example is from Ali's book @
http://ddili.org/ders/d.en/cond_comp.html:
```d
import std.stdio;
struct MyType(T) {
static if (is (T == float)) {
alias ResultType = double;
} else static if (is (T == double)) {
alias ResultType = real;
} else {
On Tuesday, 13 July 2021 at 05:37:49 UTC, ag0aep6g wrote:
On 13.07.21 03:03, someone wrote:
On Monday, 12 July 2021 at 23:28:29 UTC, ag0aep6g wrote:
[...]
I'm not sure where we stand with `in`
You mean *we* = D developers ?
Yes. Let me rephrase and elaborate: I'm not sure what the
On Tuesday, 13 July 2021 at 05:26:56 UTC, Ali Çehreli wrote:
Cumbersome because one has to make sure existing casts are
correct after changing a type.
ACK.
Harmful because it bypasses the compiler's type checking.
Hmmm ... I'll be reconsidering my cast usage approach then.
>> For
On Tuesday, 13 July 2021 at 02:34:07 UTC, Mike Parker wrote:
On Tuesday, 13 July 2021 at 02:22:46 UTC, Mike Parker wrote:
On Tuesday, 13 July 2021 at 01:03:11 UTC, someone wrote:
Being *local* to ... ain't imply visibility too regardless
scope not being a visibility attribute ? I mean, scope
On Tuesday, 13 July 2021 at 02:22:46 UTC, Mike Parker wrote:
Hopefully, my post above will shed some light on this.
Yes Mike, a *lot*.
Your previous example was crystal-clear -it makes a lot of sense
for some class usage scenarios I am thinking of but not for what
I did with my example.
On Monday, 12 July 2021 at 23:28:29 UTC, ag0aep6g wrote:
`scope` is not a visibility level.
Well, that explains why it is not listed among the visibility
attributes to begin with -something that at first glance seemed
weird to me.
`lstrSequence` is local to the function, so visibility
On Monday, 12 July 2021 at 23:25:13 UTC, Ali Çehreli wrote:
On 7/12/21 3:35 PM, someone wrote:
>>> private size_t pintSequenceCurrent = cast(size_t) 0;
>
>> Style: There's no need for the casts (throughout).
>
> [...] besides, it won't hurt, and it helps me in many ways.
I think you are doing
On Monday, 12 July 2021 at 23:18:57 UTC, jfondren wrote:
On Monday, 12 July 2021 at 22:35:27 UTC, someone wrote:
Bug: `scope` makes no sense if you want to return
`lstrSequence` (throughout).
Teach me please: if I declare a variable right after the
function declaration like this one ...
On Monday, 12 July 2021 at 05:33:22 UTC, ag0aep6g wrote:
Bug: You mixed up `wstring` and `dstring`. `wstring` is UTF-16.
`dstring` is UTF-32.
I can't believe this one ... these lines were introduced almost a
week ago LoL !
Style: `typeStringUTF` is a type, so it should start with a
On Sunday, 11 July 2021 at 05:54:48 UTC, Ali Çehreli wrote:
Ali
Primarily to Ali & Steve for their help, be advised, this post
will be somehow ... long.
Some bit of background to begin with: a week or so ago I posted
asking advice on code safeness, and still I didn't reply to the
ones
On Sunday, 11 July 2021 at 12:49:28 UTC, Adam D Ruppe wrote:
Indeed, you'd have to mixin the whole thing like
mixin("public struct " ~ lstrStructureId ~ " { ... } ");
As I mentioned in my previous reply to Ali this could be viable
for one-liners-or-so, but for chunks of code having, say, a
On Sunday, 11 July 2021 at 13:14:23 UTC, Steven Schveighoffer
wrote:
when I've done this kind of stuff, what I usually do is:
```d
struct Thing {
... // actual struct
}
mixin("alias ", lstrStructureID, " = Thing;");
```
the downside is that the actual struct name symbol will be
`Thing`,
On Sunday, 11 July 2021 at 05:54:48 UTC, Ali Çehreli wrote:
The only way that I know is to take a string parameter and use
it with a string mixin:
Yes, that I tried, but the structure has a lot of lines of codes
and so it is impractical and of course it will turn out difficult
to debug.
```d
mixin template templateUGC (
typeStringUTF,
alias lstrStructureID
) {
public struct lstrStructureID {
typeStringUTF whatever;
}
}
mixin templateUGC!(string, "gudtUGC08");
mixin templateUGC!(dstring, "gudtUGC16");
mixin templateUGC!(wstring, "gudtUGC32");
void
https://en.wikipedia.org/wiki/Luhn_algorithm#Pseudocode_implementation
On Thursday, 1 July 2021 at 19:15:50 UTC, Johan Lermer wrote:
Isn't @property kind of deprecated?
The docs state "experimental" not deprecated ... but what this
means today I don't know.
... just wondering:
I am writing pretty trivial code, nothing out of the ordinary,
and attempted to check how much of it could be marked safe ...
- Lots of tiny common library functions are pretty easy
- Getter/Setter properties are easy too
- almost all this() constructors are a no-go
On Wednesday, 30 June 2021 at 18:10:52 UTC, Alexandru Ermicioi
wrote:
That is because const/immutable/shared are being applied on the
object hence 'this' variable inside function body if function
is a member of a struct or class.
So this will make sense ONLY for an object's method right ?
I do not understand the compiler error when I add the const
keyword in the following function which works (and compiles) as
expected without the const keyword:
```d
public string getAmountSI(
in float lnumAmount
) const {
/// (1) given amount
string lstrAmount;
if (lnumAmount
On Wednesday, 30 June 2021 at 16:24:38 UTC, Andre Pany wrote:
Side note: in case you want to work with money, you may
consider using a specific data type like
https://code.dlang.org/packages/money instead of float/double.
Yes, I've seen it, and in a previous-unrelated post I commented I
am
On Wednesday, 30 June 2021 at 10:38:05 UTC, jmh530 wrote:
You've never given something away for free?
... more often than usual LoL
Now, seriously, something for free has not a price = 0, it has NO
price, that's what null is for; we use zero for the lack of null.
On Wednesday, 30 June 2021 at 09:36:34 UTC, Dennis wrote:
A `string` is not a class but an array, an `immutable(char)[]`.
You're right. My fault.
On Wednesday, 30 June 2021 at 03:55:05 UTC, Vladimir Panteleev
wrote:
If you want to give any type a "null" value, you could use
[`std.typecons.Nullable`](https://dlang.org/library/std/typecons/nullable.html).
At LEAST for some things with currency types like prices which
cannot be zero
On Wednesday, 30 June 2021 at 03:55:05 UTC, Vladimir Panteleev
wrote:
If you want to give any type a "null" value, you could use
[`std.typecons.Nullable`](https://dlang.org/library/std/typecons/nullable.html).
Practically Nullable!T stores a T and a bool.
I like the idea :)
On Wednesday, 30 June 2021 at 03:51:47 UTC, Mathias LANG wrote:
or use `std.math.isNaN`.
```d
import std.math : isNaN;
float lnumStockPricePreceding;
foreach (float lnumStockPrice; ludtStockPriceEvolution.range)
if (! isNan(lnumStockPricePreceding)) {
/// do something
}
On Wednesday, 30 June 2021 at 03:32:27 UTC, Vladimir Panteleev
wrote:
Comparison with `nan` always results in `false`:
THAT explains a lot !
See section 10.11.5:
missed it.
One of the things I do not like with D, and it causes me to shoot
me on the foot over and over, is the lack of
Is the following code block valid ?
```d
float price; /// initialized as float.nan by default ... right ?
if (price == float.nan) {
/// writeln("initialized");
} else {
/// writeln("uninitialized");
}
```
if so, the following one should be valid too ... right ?
```d
float price;
if
On Tuesday, 29 June 2021 at 23:32:21 UTC, SealabJaster wrote:
Not who you were asking but: they just don't work.
Doesn't matter, you're welcome :)
Maybe they don't support Windows for one reason or another.
Maybe their abstraction for whatever reason isn't able to
handle basic types for
On Tuesday, 29 June 2021 at 20:27:15 UTC, Alain De Vos wrote:
Some implementations take all queries full in memory.
But what when i need one record.
And the select result could be huge.
If the result is huge and you just need one record ... ain't you
coding the query wrong to begin with ?
On Tuesday, 29 June 2021 at 17:56:54 UTC, neuranuz wrote:
You could also try to find some ready to use bindings to
PostgreSQL on code.dlang.org.
Can you elaborate why you went your own way coding your own
bindings to pglib instead of using the existing ones ?
Is there something wrong with
On Monday, 28 June 2021 at 19:16:40 UTC, Alain De Vos wrote:
How to execute a random postgresql-query ?
With random i mean execute any string as known by postgresql.
void myexecutefunction(string string_to_execute){
// Some code to Execute postgre-sq-string
}
...
void main(){
On Saturday, 26 June 2021 at 04:24:05 UTC, frame wrote:
If you pass each file to the compiler like in your script then
every naming convention becomes irrelevant because the compiler
does not need to do a file system lookup anyway and a module
"foo_bar" could be also in the file xyz.d.
You
On Monday, 21 June 2021 at 13:29:59 UTC, Steven Schveighoffer
wrote:
That being said, I strongly recommend just to name the file the
same as the module name.
Although you made it clear that you do not favor this use-case I
am really satisfied with your solution because, at least to me,
has
On Thursday, 24 June 2021 at 05:39:22 UTC, jfondren wrote:
- ok, it's useful that it's like this
Albeit (the grumbling and) the weirdness of it, this is exactly
the reason why I am not complaining on such behavior -time will
show me.
On Monday, 21 June 2021 at 08:31:16 UTC, Ali Çehreli wrote:
Two options for byKey and byKeyValue:
import std;
void main() {
auto aa = [ "WS2" : 42, "WS3" : 43 ];
string strComputerIDunwanted = "WS2";
foreach (key; aa.byKey.filter!(k => k !=
strComputerIDunwanted)) {
writeln(key,
1 - 100 of 172 matches
Mail list logo
