Re: Is D programming friendly for beginners?
On Tuesday, 12 March 2024 at 16:20:29 UTC, matheus. wrote: On Tuesday, 12 March 2024 at 14:52:32 UTC, Mike Shah wrote: ... I really think D would be a wonderful first language. Fast feedback, no need to manage memory, and easy to use built-in data structures would make for a nice intro course. If you say that D would be a good language to learn in lieu C++/Rust I'd agree, but as a First Language neither one would be my choice. Most here already program and know things, but as a first language forget, at least where and when I did college (Already knowing how to program), most people were lost with all the concepts of C++ for example. Bitwise shifts like << >> and the same operators being used in cin/cout may be OK for most people already in programming and using shell, but for those learning was a hell. Matheus. I think it really depends on the person. My first language was C++, which was absolute hell to learn as a complete beginner to programming, but I really wanted to learn a language with low-level capabilities that could also do gamedev. Learning C++ as my first language was incredibly difficult, but it also made the programming parts of my CS degree a breeze - especially courses like machine level programming. Nobody else in the class even understood what a pointer was for the first couple weeks.
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis
wrote:
Of course, ultimately, different programmers have different
preferences, and none of us are going to be happy about
everything in any language.
It's not only about preferences. The feature is inconsistent
with how 'invariant' and 'synchronized' are specified. They
imply class-instance-level private, while the language dictates
module-level. Consider:
```
synchronized class C
{
private int x;
private int y;
invariant () { assert (x == y); }
}
void foo(C c)
{
// mutate c
}
```
With module-level private, 'foo' is part of C's public
interface, but it neither locks on c, nor runs the invariant
checks. I personally have no idea how to fix that sensibly
except by ditching class invariant/synchronized entirely.
This is the only valid reason for introducing class-private
that's ever been put forth in this forum. I saw someone else post
a similar argument around class invariants awhile back as well
and it completely changed my mind on the issue.
Re: DIP 1043---Shortened Method Syntax---Accepted
On Wednesday, 21 September 2022 at 10:40:42 UTC, Mike Parker wrote: On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: DIP 1043, "Shortened Method Syntax", has been accepted. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1043.md That's awesome! Congrats to Max.
Re: A look inside "filter" function defintion
On Monday, 1 August 2022 at 23:35:13 UTC, pascal111 wrote:
This is the definition of "filter" function, and I think it
called itself within its definition. I'm guessing how it works?
'''D
template filter(alias predicate)
if (is(typeof(unaryFun!predicate)))
{
/**
Params:
range = An $(REF_ALTTEXT input range, isInputRange,
std,range,primitives)
of elements
Returns:
A range containing only elements `x` in `range` for
which `predicate(x)` returns `true`.
*/
auto filter(Range)(Range range) if
(isInputRange!(Unqual!Range))
{
return FilterResult!(unaryFun!predicate, Range)(range);
}
}
'''
I think this line needs explanation:
'''D
return FilterResult!(unaryFun!predicate, Range)(range);
'''
To give a vastly simplified answer, the term "eponymous template"
essentially means that if you have an item declared inside a
template that has a same name as the template:
```D
template SomeTemplate(T)
{
alias SomeTemplate = T;
}
```
It is not a compile error. Instead, when you use the template:
```D
SomeTemplate!int n;
```
The compiler rewrites your code like to:
```D
SomeTemplate!int.SomeTemplate n;
```
Because normally when you instantiate a template, you have to
refer to the declarations inside it by name:
```D
template SomeOtherTemplate(T)
{
alias SomeAlias = T;
}
//SomeOtherTemplate!int n; Error: `SomeOtherTemplate!int` is used
as a type
SomeOtherTemplate!int.SomeAlias n; //Ok
```
Except in the special case I outlined above. It's essentially a
hack that was brought over from C++. It makes using templates
more ergonomic.
Re: Fix template parameter
On Monday, 8 August 2022 at 12:02:02 UTC, Dom Disc wrote: Hello. I found in the documentation functions declared like this: ```D pure @nogc @safe BigInt opAssign(T : BigInt)(T x); ``` This is a template function, even if T is constrained to always be BigInt (it may also include anything that is a subtype of BigInt... I've received different answers on what exactly `(T: SomeType)` means in this context). This means that it cannot be virtual, you can't take its address, and as bauss said, it won't show up in the object file if it's not used. As far as I know, there's no advantage to doing this over `opAssign(BigInt x)`, UNLESS `(T: BigInt)` means "BigInt and any subtype of BigInt", in which case the advantage is similar to doing ` void opAssign(T val)` in Java (referring to polymorphism; this won't give you virtual dispatch like it does in Java).
Re: Release D 2.099.0
On Wednesday, 9 March 2022 at 12:06:40 UTC, evilrat wrote: On Wednesday, 9 March 2022 at 10:08:50 UTC, meta wrote: On Wednesday, 9 March 2022 at 09:04:03 UTC, Martin Nowak wrote: Glad to announce D 2.099.0, ♥ to the 100 contributors. This release comes with __traits(parameters), unittests only from root modules, throw expressions, and plenty of more changes. http://dlang.org/download.html http://dlang.org/changelog/2.099.0.html -Martin The download links doesn't work.. I get access denied, what is happening? Are CI/CD builds available somewhere? on GitHub? it seems like upload script error, download link is https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2021/dmd-2.099.0.exe but if you change it to (notice 2022 instead of 2021) https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2022/dmd-2.099.0.exe it now works I still get access denied error on the download page, nobody test the releases? I had a similar issue for downloaded the beta, and it was still not fixed.. This needs to be sorted out, it's 2 release in a row that is messed up
Re: Release D 2.099.0
On Wednesday, 9 March 2022 at 09:04:03 UTC, Martin Nowak wrote: Glad to announce D 2.099.0, ♥ to the 100 contributors. This release comes with __traits(parameters), unittests only from root modules, throw expressions, and plenty of more changes. http://dlang.org/download.html http://dlang.org/changelog/2.099.0.html -Martin The download links doesn't work.. I get access denied, what is happening? Are CI/CD builds available somewhere? on GitHub?
Re: trash-d version 15
On Tuesday, 8 March 2022 at 14:29:07 UTC, rushsteve1 wrote: Hello! I thought I would give an update on `trash-d`, the utility that I've been writing in D for the last several months. https://github.com/rushsteve1/trash-d Previous announcement thread: https://forum.dlang.org/thread/onpukmibdjhtwwsva...@forum.dlang.org Since my last post there have been a number of new releases, the latest being version 15 which I tagged yesterday. `trash-d` can now handle cross-device trashing, report orphaned files in the trash, presents info as nicer tables, and there are now DEB and RPM packages built by CI. And a whole host of bugfixes and smaller features, as well as a pretty solid test set with about 85% coverage. I'm still a bit of a D novice, so any feedback or suggestions (or PRs) are highly appreciated! That's a very nice project, thanks for sharing, the code is very clean and easy to read, well done! The only note I can make so far is the lack of proper modules ``module x;`` I'm surprised you could import other files without it, is it common practice to ignore that rule when everything is top level?
Re: Colors in Raylib
On Tuesday, 1 March 2022 at 15:37:55 UTC, Ali Çehreli wrote:
On 3/1/22 07:19, Mike Parker wrote:
> On Tuesday, 1 March 2022 at 13:15:09 UTC, meta wrote:
>
>>
>> enum Color
>> { GRAY }
>>
>> void setColor(Color color);
>>
>> setColor(GRAY);
>
> Then that defeats the purpose of having named enums.
Yes and no.
meta is pointing at a difference between the above and the
following:
writeln(GRAY);
In the latter case, the compiler has no clue whether I intended
to type GRAM. But in the former case, the type is Color. What
remains is whether the compiler should be looking deep into
Color and have a list of values to lower GRAY to Color.GRAY.
We heard this before for the switch statement: When the
variable is Color, the case values can be accepted as Color as
well (without the qualifier). (Yes, 'with' works as well, but
the idea is the same.)
It feels the same for even int because we don't write int(42)
when passing an int argument:
void foo(int) {}
foo(int(42)); // works
foo(42); // works as well
So the lack of this compiler help does not bother me but still,
I think the request is meaningful.
Ali
Yes, that's exactly the point I was trying to make, thanks Ali!
Re: Colors in Raylib
On Tuesday, 1 March 2022 at 12:29:56 UTC, Steven Schveighoffer
wrote:
On 3/1/22 7:22 AM, meta wrote:
If the type is ``Color`` I think the compiler should allow
``GRAY`` if it is a member of ``Color``, isn't how strong
statically typed language should work? I wonder what is the
rational against it? How hard would it be to allow it?
The problem is how the original source works.
The only way to define a manifest constant for a struct
instance in C is to #define it.
So I'm sure that if raylib could put that inside the `Color`
type it would, but it can't.
What a D binding should do is exactly what Mike said -- provide
a complete binding as expected, and then add machine-generated
nicer APIs.
I actually have an open issue, in case anyone is interested in
working on it: https://github.com/schveiguy/raylib-d/issues/8
-Steve
Oh I was talking with regard to D's enum, not about the binding,
allowing it via D, would make interfacing with C code easier
enum Color
{ GRAY }
void setColor(Color color);
setColor(GRAY);
Re: Colors in Raylib
If the type is ``Color`` I think the compiler should allow ``GRAY`` if it is a member of ``Color``, isn't how strong statically typed language should work? I wonder what is the rational against it? How hard would it be to allow it?
Re: D Language Foundation Monthly Meeting for February 2022
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote: ### Vladimir Vladimir opened with a progress report. Back in December, [we discussed migrating our Bugzilla issues to Github](https://forum.dlang.org/post/wnnwxyjtizvhyswwq...@forum.dlang.org). An alternative solution is to [upgrade to Bugzilla Harmony](https://github.com/bugzilla/harmony), a project Vladimir had been contributing to for some time. After that meeting, we agreed that Robert Schadek would move forward with implementing his migration script, while Vladimir would get the new Bugzilla instance set up so we can test it out in the interim. I was looking forward the Github migration.. I'm not liking the constant switch from Github/bugzilla, referencing/looking for issues is also a major pain.. LLVM recently migrated fully to Github/Github Issues, that's is the way to go in my opinion.. Can't beat the nice integration and ease of access Github provides, we need stay fresh to attract new younger souls
Re: https://run.dlang.io/ vs All dmd compilers (2.060 - latest)
Is the source of 'run.dlang.io' available somewhere?
Re: split Error - no overload matches
A trick i use often:
```D
import std;
void main()
{
import uni = std.uni;
writeln("Learning D is fun".split!(uni.isWhite));
}
```
Under-rated way of importing things, you don't bloat your scope
anymore
Re: Added copy constructors to "Programming in D"
On Thursday, 10 February 2022 at 20:34:29 UTC, Walter Bright wrote: On 2/10/2022 12:06 AM, Mathias LANG wrote: I think an *immediate* improvement we could make to ease people's life is to make `auto` peel the outermost qualifier level inside functions. So that: ```D const int* ptr; auto p2 = ptr; static assert(is(typeof(p2) == const(int)*)); ``` I really can't think of any downside to it, only upsides: - It is still predictable / consistent; - It *might* reduce the number of template instantiations in some cases; - It just flows more naturally... If you want full constness, there's still `const`; It sounds sensible to me. Didn't Scott Meyers cover exactly this in his "the last thing D needs" talk? It seems like a really bad idea.
Re: Added copy constructors to "Programming in D"
Why do we even bother with `in` when we can do:
alias In(T) = const scope T;
void test(In!int n) {
pragma(msg, typeof(n));
}
?
onlineapp.d(3): Deprecation: storage class `scope` has no effect
in type aliases
const(int)
...oh
Re: What is the meaning of @future ?
On Friday, 17 September 2021 at 10:31:34 UTC, bauss wrote: On Thursday, 16 September 2021 at 20:53:34 UTC, Elmar wrote: Hello D community. I was browsing the `__traits` keywords and I found `isFuture` whose descriptions says something about `@future`-annotated variables. [link](https://dlang.org/spec/traits.html#isFuture) I didn't find anything about `@future` for the D programming language. I only found that this annotation is used in Apex to denote futures (a.k.a. promises) as programming concept. Is this something which exists, existed, was abandoned early as an idea? I remember I had read that D uses a "fiber" library to provide coroutines and such. Maybe somebody knows an answer for this. It's just another "useless" attribute that the language has added before fixing any of the real problems :) Basically it reserves a symbol for the future. It's similar to creating ex. an empty function that throws an error or something like "Not implemented" While I understand why it was added and what purpose it serves then I fail to see why that was prioritized over actual issues. It's solving an almost non-existing issue. I think the main reason it was added is because Sociomantic asked for it, but they are of course not around anymore.
Re: nothrow and std.exception.ifThrown
On Friday, 30 April 2021 at 13:42:49 UTC, Steven Schveighoffer
wrote:
On 4/30/21 9:24 AM, Meta wrote:
My point is that I think marking the *function* nothrow is not
correct, it's the second parameter that dictates the throwing
of the result.
And you can probably fix the second parameter to be a templated
delegate:
```d
CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1,
T2)(lazy scope T1 expression, scope T2 errorHandler) if
(is(typeof(errorHandler(E.init
```
And of course, we get into chicken-and-egg problems with this
because if you pass in a lambda, there's no types for it to
figure this stuff out. Another option is to overload on the
delegate, but meh. I'd really like to see a language change
that says "infer the attributes of this function based on the
fact that it calls the delegate passed in."
-Steve
Now that you mention it, I don't see why lazy parameters can't
have their attributes inferred. What happened to the DIP to
replace lazy parameters with automatic conversion of passed
values to delegates, anyway? I.e.:
```
CommonType!(T1, T2) ifThrown(E: Throwable = Exception, T1,
T2)(scope T1 delegate() expression, scope T2 delegate()
errorHandler);
//getString() and "some string" automatically converted to
`string delegate()`
auto s = getString().ifThrown("some string");
```
Re: nothrow and std.exception.ifThrown
On Thursday, 29 April 2021 at 20:00:23 UTC, novice2 wrote:
i dont understand why (templates too dificult for me yet),
but if i comment "lazy" from T2,
then compiler allow add "nothrow" to "ifThrown"
```d
CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1,
T2)(lazy scope T1 expression, /*lazy*/ scope T2 errorHandler)
nothrow
```
https://run.dlang.io/is/KTdd3G
This is because marking a function parameter as `lazy` is just
syntax sugar for the following:
```
CommonType!(T1, T2) ifThrown(E: Throwable = Exception, T1,
T2)(scope T1 delegate() expression, scope T2 delegate()
errorHandler);
string def = "some string";
auto s = format("%d", x).ifThrown({ return def; });
```
Behind the scenes, a `lazy` parameter is not really a value -
it's a function that _returns_ a value. The problem is that this
function is not `nothrow`, and can't be marked as such (this is
arguably a gap in the language). Removing `lazy` changes
`errorHandler` to be a plain old value again - which cannot throw
an exception, of course - so `ifThrown` can be marked `nothrow`.
However, you lose all the benefits of `errorHandler` being lazily
computed.
Re: nothrow and std.exception.ifThrown
On Friday, 30 April 2021 at 13:05:00 UTC, Steven Schveighoffer wrote: On 4/29/21 1:50 PM, Meta wrote: The reason for this, apparently, is in the definition of `ifThrown`: ``` CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1, T2)(lazy scope T1 expression, lazy scope T2 errorHandler) nothrow ``` It's not marked as `nothrow` in the function's definition, so even if the delegate passed to ifThrown _is_ nothrow, the compiler can't tell. There's no easy way around this that I can think of OTOH that doesn't involve some effort on your part. Wait, I don't get what you are saying. You mean it should be marked nothrow? It's a template, so it *should* be inferred nothrow if it were actually nothrow. The current definition is not marked nothrow as you alluded, and when I do mark it nothrow, it complains that the lazy parameter used for the exception handler is not nothrow. It seems there's no way to infer the throwing of the lazy parameter, lazy parameters are never nothrow. The higher order function DIP would I think help with this. -Steve Change it to a delegate and it's the same thing. ifThrown being a template is irrelevant in this case because it is accepting the handler as a function argument, not a template argument. You: 1. Need to make it a delegate instead of a lazy argument. 2. Need to mark the delegate as nothrow. For the function to be inferred as nothrow.
Re: nothrow and std.exception.ifThrown
On Thursday, 29 April 2021 at 16:02:20 UTC, novice2 wrote:
Hello.
I need use std.format.format() in nothrow function.
format() can throw.
For this case i have special default string.
I don't want embrace format into try..catch block,
and i found elegant std.exception.ifThrown.
But DMD say "ifThrown not nothrow"
https://run.dlang.io/is/kXtt5q
```d
nothrow string foo(int x, string def) {
import std.format: format;
import std.exception: ifThrown;
return format("%d", x).ifThrown(def);
}
Error: function std.exception.ifThrown!(Exception, string,
string).ifThrown is not nothrow
```
What i can use instead of ifThrown, or how it can be changed to
nothrow?
Thanks.
The reason for this, apparently, is in the definition of
`ifThrown`:
```
CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1,
T2)(lazy scope T1 expression, lazy scope T2 errorHandler) nothrow
```
It's not marked as `nothrow` in the function's definition, so
even if the delegate passed to ifThrown _is_ nothrow, the
compiler can't tell. There's no easy way around this that I can
think of OTOH that doesn't involve some effort on your part. One
thing you can do is wrap ifThrown with
`std.exception.assumeWontThrow`:
```
import std.exception: ifThrown, assumeWontThrow;
import std.functional: pipe;
alias ifThrown = pipe!(std.exception.ifThrown, assumeWontThrow);
nothrow string foo(int x, string def) nothrow {
import std.format: format;
return format("%d", x).ifThrown(def);
}
```
Re: Is there a more elegant way to do this in D?
On Thursday, 8 April 2021 at 18:01:56 UTC, Meta wrote:
On Thursday, 8 April 2021 at 12:19:29 UTC, WebFreak001 wrote:
```d
string to01String(int[] x) @safe
{
auto conv = x.to!(ubyte[]); // allocates new array, so
later cast to string is OK
conv[] += '0'; // assume all numbers are 0-9, then this
gives the correct result
return (() @trusted => cast(string)conv)();
}
```
The @trusted lambda can also be replaced with
[std.exception.assumeUnique](https://dlang.org/library/std/exception/assume_unique.html).
Never mind me, assumeUnique is @system (or at least it's inferred
as @system), and anyway, you can't implicitly convert
`immutable(ubyte)[]` to `immutable(char)[]`.
Re: Is there a more elegant way to do this in D?
On Thursday, 8 April 2021 at 12:19:29 UTC, WebFreak001 wrote:
```d
string to01String(int[] x) @safe
{
auto conv = x.to!(ubyte[]); // allocates new array, so
later cast to string is OK
conv[] += '0'; // assume all numbers are 0-9, then this
gives the correct result
return (() @trusted => cast(string)conv)();
}
```
The @trusted lambda can also be replaced with
[std.exception.assumeUnique](https://dlang.org/library/std/exception/assume_unique.html).
Re: Is this bug ? format %(%)
On Wednesday, 7 April 2021 at 17:31:09 UTC, Paul Backus wrote:
On Wednesday, 7 April 2021 at 17:04:56 UTC, novice2 wrote:
On Wednesday, 7 April 2021 at 13:43:18 UTC, Paul Backus wrote:
So, you should change your code to
writefln("%-(%s, %)", s);
sorry i dont read docs so carefully
thanks
It's not your fault--this is a pretty obscure feature, and it's
not documented very well. Even after you've found the correct
page in the documentation (the page for `formattedWrite` [1]),
you have to scroll down past multiple examples to find the text
that explains it.
[1] https://dlang.org/phobos/std_format.html#formattedWrite
I have created a pull request that will hopefully make this more
prominent on the doc page:
https://github.com/dlang/phobos/pull/7944
Re: Immutable
On Saturday, 27 March 2021 at 20:44:12 UTC, Brad wrote: I was looking through lots of sample code on Rosetta Code. D has a lot of solutions out there. That is really nice but it has me wondering - coming from other languages that do not support the concept of immutability - do real world programmers and/or hobbyists really use it as much as I see it on Rosetta Code? I know it adds a layer of security to your code, but I am still thinking "why?". Thanks for entertaining a newbie question. FYI, most of those examples were written by someone who goes by "Bearophile", and their style of writing D uses immutable/const/pure/nothrow/etc. wherever possible. It's not necessarily the style that all D programmers use, though there are a number of people that do. As for advantages, when it comes to the basic value types (int, float, bool, etc.), it's not all that useful. Where immutable can become very useful, though, is with types that have indirections (i.e. pointers). D's `string` type, for example, is actually a simple alias in Druntime: alias string = immutable(char)[]; Meaning "a mutable array of immutable chars". This means that you can modify the array itself, such as changing its length, appending to it, etc., but you cannot its individual elements. E.g., the following will work: string s1 = "this is a string"; s1 ~= '.'; assert(s1 == "this is a string."); But this will NOT work: string s2 = "this is a string "; s2[$ - 1] = '.'; Error: cannot modify immutable expression s2[__dollar - 1LU] This is just a simple example, but it allows the compiler to do some major optimizations on string handling code. Something that is usually very slow in C/C++ is such code, because strings are mutable arrays of mutable characters. Thus, they have to be copied around everywhere, which is slow and uses a lot of memory unnecessarily. Not so in D; because strings are mutable arrays of immutable characters, you can freely pass out references to the whole string, or a subrange of it. This would be very dangerous in C/C++, but in D you don't have to worry about the string changing out from under you by some code somewhere else in the program that you gave a reference to. Thus, string handling code is far faster in D than in C/C++. That is just one example, but you can see how immutable makes possible a lot of optimizations that would simply be impossible in languages without it.
Re: Release D 2.096.0
On Sunday, 14 March 2021 at 05:31:27 UTC, Max Haughton wrote: On Sunday, 14 March 2021 at 03:25:28 UTC, starcanopy wrote: On Saturday, 13 March 2021 at 21:33:20 UTC, Meta wrote: It's pretty neat, but a DIP has to be drafted and approved for it to be enabled by default, right? (Unless I missed it.) Correct. To be completely honest it shouldn't have ever been merged since there was no approval from WalTila and they steer the language. I raised a similar concern before with something else (don't remember what it was), but apparently things can be merged without W's approval if they're behind a switch (in the opinion of at least some of the core maintainers, at least).
Re: Release D 2.096.0
On Saturday, 13 March 2021 at 21:15:40 UTC, Martin Nowak wrote:
Glad to announce D 2.096.0, ♥ to the 54 contributors.
This release comes with improved ABI compatibility for complex
types, clarified copy constructor and postblit interaction,
optional libunwind based backtraces, runtime-allocated global
synchronized mutexes, and a preview for shortened lambda-style
function definitions.
http://dlang.org/download.html
http://dlang.org/changelog/2.096.0.html
-Martin
Allow shortened function implementations for single-expresssion
functions.
-preview=shortenedMethods is added. This allows functions to be
written in a similar form to lambda functions:
// these 2 are equivalent
int foo() { return 1; }
int foo() => 1;
The syntax allows the form => expr to replace the function body {
return expr; }
Amazing! I had no idea this got in. I love the syntax.
Re: Very confusing error message when calling a class method from an invariant
On Wednesday, 10 March 2021 at 04:57:19 UTC, Paul Backus wrote:
On Wednesday, 10 March 2021 at 03:39:15 UTC, Meta wrote:
class Human {
static immutable MAX_AGE = 122;
bool alive = true;
int age = 0;
//Error: mutable method onlineapp.Human.checkAge is not
callable using a const object
invariant(checkAge());
[...]
What the hell does this even mean, and where does it come
from? Adding `inout` to `checkAge` actually does cause it to
compile and run too. WTF?
From the language spec [1]:
The invariant is in the form of a const member function.
So, inside the invariant, the object is treated as const, which
means you can't modify it and can only call const methods.
[1] https://dlang.org/spec/class.html#invariants
Now that you mention it, I'm pretty sure I've run into this
before; I must've forgotten about it. I understand the rationale
behind this, but it doesn't really make sense IMO that only
invariants treat the object as const, and not pre/post conditions
as well. Ah well. Thanks for quick answer.
Very confusing error message when calling a class method from an invariant
class Human {
static immutable MAX_AGE = 122;
bool alive = true;
int age = 0;
//Error: mutable method onlineapp.Human.checkAge is not
callable using a const object
invariant(checkAge());
void growOlder()
in(alive)
out(; checkAge())
{
age++;
if (age > MAX_AGE)
die();
}
void die()
in(alive)
out(; !alive) {
alive = false;
}
bool checkAge() {
return age >= 0 && age <= MAX_AGE || !alive;
}
}
void main() {
Human h = new Human();
h.growOlder();
}
What the hell does this even mean, and where does it come from?
Adding `inout` to `checkAge` actually does cause it to compile
and run too. WTF?
Re: Bubel ECS - Entity-Component-System architecture implementation
On Tuesday, 9 March 2021 at 15:21:26 UTC, Mergul wrote: On Tuesday, 9 March 2021 at 14:29:37 UTC, Meta wrote: Awesome! In the demo, I noticed that if there are >3000 entities spawned, there will be periodic dips in the FPS. Could this be Javascript's GC kicking in? What browser are you using? I've tested couple of browsers. In general JavaScript shouldn't be a problem, from what I know WASM only growth its memory. Library itself almost never call malloc (so memory is always allocated). On firefox I had problem with FPS most of a time and I'm not sure what cause this problem (I found several bug reports which could be related to that). Besides Firefox every web browser I tested was based on chromium engine. I didn't see any periodic dips, even with <200k entities. Maybe there is some problem related to WebGL or JS Workers. When JS side detects that WASM threads are enabled in browser it loads multithreaded version of WASM code and spawn workers. But overall multithreaded execution is always more stable for me. This is in Chrome 88.0.4324.192 on my 2015 Macbook Pro.
Re: Bubel ECS - Entity-Component-System architecture implementation
On Tuesday, 9 March 2021 at 16:36:31 UTC, ryuukk_ wrote: That's impressive, and shows the D capabilities, the future is WASM!!! glad to see D ready for it! Yes, I forgot to mention this, but WASM support out of the box is awesome!
Re: Bubel ECS - Entity-Component-System architecture implementation
On Monday, 8 March 2021 at 19:45:58 UTC, Mergul wrote: Hello everyone, I'm glad to announce release of my Bubel ECS library. Bubel ECS is Entity-Component-System architectural pattern implementation in D language. Library aims to delivery fast and flexible architecture for developing games. It's @nogc and betterC compatible. WASM is supported through Emscripten. Library has no external dependencies and was tested on Linux, Windows, Android and WASM. Project was developed in data oriented designed fashion and supports multithreading with automatic job generation. For more information go to Gitlab repository page. Its beta version but core is fully functional and finished. I have planned some bigger features like Worlds support, better events handling or even C-API which can lead to some changes in API. If you want try Bubel ECS I prepared demo which works in browers through WASM (Emscripten) and even supports multithreading (on Chromium based browsers, Firefox had some performance issues even on single threaded version when last tested) Demo is still WIP and it can be hard to understad how it works (how to use its features). There is possibility to enable/disable almost all systems in runtime and changing components and data for all entities. All components and systems are exact representation of what they are in code. I'm using Gitlab CI for automated testing (betterC testing included) Note: Library support multithreading but has no code for actual parallel execution, it only generates jobs and dependencies. In demos I'm using mmutils.thread_pool (my brother's library) .I will add simple integration code for it in near future for people who wants multithreading working out-of-the-box. Dub: https://code.dlang.org/packages/bubel_ecs Gitlab: https://gitlab.com/Mergul/bubel-ecs Documentation: https://mergul.gitlab.io/bubel-ecs/ecs.html Wiki: https://gitlab.com/Mergul/bubel-ecs/-/wikis/home (WIP I've started making tutorial there) Online demo: https://mergul.gitlab.io/bubel-ecs/ecs_demo.html Awesome! In the demo, I noticed that if there are >3000 entities spawned, there will be periodic dips in the FPS. Could this be Javascript's GC kicking in?
Re: Beta 2.096.0
On Sunday, 28 February 2021 at 11:56:28 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.096.0 release, ♥ to the 53 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.096.0.html As usual please report any bugs at https://issues.dlang.org -Martin "Support for instantiating local and member templates with local symbols was implemented in DMD 2.087.0. However, the implementation was incompatible with GDC and LDC backends. In order to maintain feature parity among D implementations, this improvement has been deprecated, and may be removed from a future DMD release." Urgh, so sad this was deprecated. Is the implementation being redone at some point?
Re: DIP 1034--Add a Bottom Type (reboot)--Formal Assessment Concluded
On Tuesday, 16 February 2021 at 07:07:09 UTC, Mike Parker wrote: When I emailed Walter and Atila to officially launch the Formal Assessment of DIP 1034, "Add a Bottom Type (reboot)", I expected it would be three or four weeks before I received their final decision. So I was surprised when Walter replied two days later with the following response: "Accepted with pleasure and enthusiasm. This is what DIPs should be like. I intuitively felt that a bottom type was right for D, but failed to express it in DIP1017. Dennis has done it right." Atila was on vacation at the time, but as soon as he got back he responded: "Seconded." Congratulations to Dennis Korpel for a job well done, and thanks to everyone who provided feedback on this DIP from the Draft Review through to the Final Review. Great news! Congrats to Dennis.
Re: Say Hello to Our Two New Pull-Request/Issue Managers
On Wednesday, 13 January 2021 at 11:33:44 UTC, Mike Parker wrote: I'm very, very happy that I can finally announce the news. Some of you may recall the job announcements I put out on the blog back in September [1]. Symmetry Investments offered to fund one full-time, or two part-time, Pull Request Manager positions, the goal being to improve the efficiency of our process (prevent pull requests from stagnating for ages, make sure the right people see the PRs in need of more than a simple review, persuade the right people to help with specific Bugzilla issues, etc). Several people applied for the job, including some unknown in the D community. Ultimately, two people were selected: one to fill an administrative/managerial role, the other to fill a more technical role. Today I can tell you who they are. Please congratulate Andrew Edwards and Razvan Nitu on their new positions! They have already been on the job for several days and are eager to make a difference. Currently, their responsibilities are outlined here at: https://dlang.org/foundation/prman.html Please consider this a living document. We will amend and revise it as we learn more about what they and the community need for them to do this job right. I ask that everyone please give them time to settle in. I expect we'll hear from them once they have, with some details regarding how they'll perform their duties and any relevant information for contributors. Congratulations to Andrew and Razvan, and tremendous thanks to Symmetry for making this happen. [1] https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/ That's great! Congrats to Razvan and Andrew, and thanks to Symmetry for sponsoring the positions.
Re: Our community seems to have grown, so many people are joining the Facebook group
On Monday, 28 December 2020 at 17:31:21 UTC, Murilo wrote: In the past 2 weeks we went from 225 to 240 members in our Facebook group(https://www.facebook.com/groups/ProgrammingInDlang), an average of a person per day. First it was an average of a person per month or less. I wonder if someone has advertised the group or the world is finally embracing Dlang now. In 2018 I didn't find a single Dlang Facebook active group, there were 1 or 2 very old groups with no members. So I created one and I've been working hard to make it official and big, it worked! At first I added my friends list to give it number but then, as people joined it, I removed all of my friends and left only people who joined voluntarily, there were only 150, over time it grew to 225 and now we are getting close to 250. At first there was only a post per week, all posted by me, now I don't need to post something every week because the members are already doing it themselves, there is regular activity including posts and discussions. I'm very happy, at first the people here did not like my idea, they thought a Facebook group was unnecessary, but what is the biggest social media in the world? Facebook! So that's is the best way to communicate with the world and advertise Dlang. Cheers. Cool, I didn't know this exists. Congrats on 200+ members; that's no mean feat!
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 21:19:02 UTC, Seb wrote: On Thursday, 1 October 2020 at 21:09:55 UTC, Meta wrote: On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: [...] Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview? Approval is not required for -preview. It's the testing phase of a new feature or change. As I tried to mention earlier real data and experimentation is super helpful for a DIP / formal approval (in this case one important question answered was how much code in the D ecosystem would need to be changed). There's a bit of implicit approval by no objection as something that's worthwhile to be explored/tested, but it's only a good chance that it will be activated by default, not a guarantee. Okay, fair enough. Looks like I was mistaken and thought -preview implied that the feature will be moved out from under the switch after a certain number of releases (as the word "preview" means an early look at something that will be released in the future).
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: I've read the discussion but skipped the presentation. All I see is Atila expressing distaste for the compiler choosing how to pass values, and no explicit sign-off from either Walter or Atila before it was merged. My objection is not to `in`'s new behaviour (although having something that functions similarly to auto ref but in subtly different ways is not good language design, IMO). My objection is that we have a major change to a language feature, that was merged without the apparent blessing of either of the two people who are supposed to be the gatekeepers for these decisions, and without a DIP (yes, it is behind -preview, but that implies that this will eventually make it into the language proper). That is what I am calling "ridiculous". If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. You seem to have a wrong understanding of -preview. It doesn't even pretend to be an officially approved feature. I think this is what's been causing the confusion. Preview flags are what other compilers call "experimental". In fact, -preview is intended to predate a DIP or formal approval in other ways, because if you don't know the impact of a feature or usefulness, it's very hard to make an informed decision. This has the nice side effect that sometimes it becomes clear during an implementation that the idea as is unfeasible. implies that this will eventually make it into the language proper No, it doesn't. Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview?
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 20:37:04 UTC, kinke wrote: On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. https://github.com/dlang/dmd/pull/11000#issuecomment-675605193 As far as I understand it, Andrei does not have any say over the direction of the language anymore since he stepped down. By "W or A" I meant "Walter or Atila".
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 16:19:48 UTC, Steven Schveighoffer wrote: On 10/1/20 10:36 AM, Meta wrote: On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. Why was this added when we already have `auto ref`? Yes, it makes the function a template, but if `in` can automatically choose whether the variable is ref or not, then auto ref could easily do the same. There is a difference. `in` is choosing it based on the type, not whether it's an rvalue or lvalue. auto ref doesn't care whether it's an int or a 1k-sized struct, if it's an lvalue, it's ref, and if it's an rvalue, it's non-ref. This seems ridiculous to me. We now have ANOTHER way of asking the compiler to choose for us whether to pass by ref or by value, completely mutually exclusive of auto ref. Where was the DIP (apologies if I just didn't see it)? Did Walter approve this? How do we explain the difference between in and auto ref with (as Andrei would say) a straight face? Not only that, but every auto-ref parameter is another template parameter varying on the usage. So calling on an lvalue and rvalue will generate 2 separate mostly-identical functions. With -preview=in, only one function is generated per type. That's a QOI problem IMO. -Steve
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. Why was this added when we already have `auto ref`? Yes, it makes the function a template, but if `in` can automatically choose whether the variable is ref or not, then auto ref could easily do the same.
Re: opBinary : Static ifs or specialization?
On Tuesday, 23 June 2020 at 23:53:36 UTC, claptrap wrote:
So you have opBinary and half a dozen operators to implement.
Do you use a separate method for each operator or do you have
one method and a big static if else if to select code path?
I assume they are functionally equivalent? So its just about
style?
An idiomatic example:
import std.algorithm: among;
struct Test
{
int payload;
Test opBinary(string op)(Test other)
if (op.among!("+", "-", "*", "/")) //Limit supported ops
{
mixin("return Test(payload " ~ op ~ "other.val);");
}
int opBinary(string op)(int n)
//No constraint; support the full range of integer operations
{
mixin("return payload " ~ op ~ "n;");
}
}
Re: News on the D Blog: SAOC 2020 and More
On Tuesday, 23 June 2020 at 13:45:56 UTC, user1234 wrote: On Tuesday, 23 June 2020 at 12:00:30 UTC, Mike Parker wrote: On Tuesday, 23 June 2020 at 12:00:06 UTC, Mike Parker wrote: Symmetry Autumn of Code 2020 is on! My latest news post on the D Blog talks about that, some D Language Foundation finance updates, and whispers on the wind. And you can read all about it here: https://dlang.org/blog/2020/06/23/saoc-2020-and-other-news/ "Thanks are also in order to those who have supported the foundation through smile.amazon.com. Your purchases have brought over $288" That is interesting, that means that dlang users spent ~57,600.0 bucks on Amazon recently. And that's probably only a minority as people don't necessarily remembers that smile.amazon thing. I guarantee I spent at least $1000 on Amazon in 2019, and I've ordered a lot of stuff off there that I wouldn't normally, given the quarantine. I don't usually buy from amazon.com as I'm not in the US, but I did set mine to donate to the DLF when I do.
Re: Should a parser type be a struct or class?
On Wednesday, 17 June 2020 at 11:50:27 UTC, Per Nordlöw wrote: Should a range-compliant aggregate type realizing a parser be encoded as a struct or class? In dmd `Lexer` and `Parser` are both classes. In general how should I reason about whether an aggregate type should be encoded as a struct or class? IMO it doesn't need to be. However, it's worth saying that range semantics aren't a great fit for parsers - at least that's been my experience. Parsers need to be able to "synchronize" to recover from syntax errors, which does not fit into the range API very well. You can probably fit it in somewhere in popFront or front or empty, as your implementation permits, but I find it's just easier to forego the range interface and implement whatever primitives you need; *then* you can add a range interface over top that models the output of the parser as a range of expressions, or whatever you want.
Re: DIP 1028 "Make @safe the Default" is dead
On Friday, 29 May 2020 at 12:22:07 UTC, Steven Schveighoffer wrote: On 5/29/20 12:53 AM, Walter Bright wrote: The subject says it all. If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best. For everyone else, carry on as before. Thank you Walter. I'm sure this was not easy to decide, and is frustrating. It's unfortunate that the thrust of DIP1028 could not be saved and we had to throw out the whole thing for the one bad piece. It's not unfortunate - it's unnecessary. @safe by default is still a laudable and (seemingly) attainable goal. Why throw out the entire DIP instead of removing or altering the controversial aspect?
Re: Retrieve the return type of the current function
On Tuesday, 5 May 2020 at 18:19:00 UTC, Meta wrote:
mixin template magic()
{
alias CallerRet = typeof(return);
CallerRet magic()
{
return CallerRet.init;
}
}
Small edit: you can remove the "CallerRet" alias by doing the
following:
mixin template magic()
{
typeof(return) magic()
{
return typeof(return).init;
}
}
Though I wouldn't really recommend it as it's very confusing,
IMO. This works because "typeof(return)" in the return position
here refers to the caller's scope, while "typeof(return)" inside
the function refer's to the function's scope.
Re: Retrieve the return type of the current function
On Tuesday, 5 May 2020 at 17:11:53 UTC, learner wrote:
On Tuesday, 5 May 2020 at 16:41:06 UTC, Adam D. Ruppe wrote:
typeof(return)
Thank you, that was indeed easy!
Is it possible to retrieve also the caller return type?
Something like:
```
int foo() {
return magic();
}
auto magic(maybesomedefaulttemplateargs = ??)() {
alias R = __traits(???); // --> int!
}
```
Mixin templates maybe?
You *can* use mixin templates to access the caller's scope, which
means typeof(return) will refer to the caller's return type,
instead of the callee's. However, there's no way to both mixin
and call the mixin template in a single line, so it's not DRY:
int foo()
{
mixin magic;
return magic();
}
mixin template magic()
{
alias CallerRet = typeof(return);
CallerRet magic()
{
return CallerRet.init;
}
}
void main()
{
foo();
}
Maybe somebody else knows a way to get around having to first
mixin magic.
Re: Checked!({short, ushort, byte, char}, Throw): compilation fails
Unlike C/C++, char is not a numeric type in D; It's a UTF-8 code
point:
import std.traits;
void main()
{
pragma(msg, isNumeric!char); //Prints false
}
Re: Discord bot written in D
On Monday, 6 April 2020 at 21:23:22 UTC, Quantium wrote: Are there any libraries to creade a simple discord bot using D? And if you know these libraries, could you day me their pros and cons? I've used https://github.com/b1naryth1ef/dscord to build a Discord bot, a little over a year ago. However, it didn't even seem that actively maintained back then; I had to patch over at least one bug. Other than that, though, it worked smoothly and was easy to get started with.
Re: Our HOPL IV submission has been accepted!
On Saturday, 29 February 2020 at 01:00:40 UTC, Andrei Alexandrescu wrote: Walter, Mike, and I are happy to announce that our paper submission "Origins of the D Programming Language" has been accepted at the HOPL IV (History of Programming Languages) conference. https://hopl4.sigplan.org/track/hopl-4-papers Getting a HOPL paper in is quite difficult, and an important milestone for the D language. We'd like to thank the D community which was instrumental in putting the D language on the map. The HOPL IV conference will take place in London right before DConf. With regard to travel, right now Covid-19 fears are on everybody's mind; however, we are hopeful that between now and then the situation will improve. That's great. Congratulations to the three of you and thanks for all the hard work on this.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 18:07:19 UTC, Arine wrote:
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright
wrote:
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't work with writef
5. non-default formats require extra temp strings to be
generated
Sometimes I wonder if you even bother to read posts to
understand.
This is a problem with YOUR DIP. Where you said, "what's wrong
with that, it's working as intended".
void CreateWindow(string title, int w = -1, int h = -1);
int a;
CreateWindow(i"Title $a");
// becomes
CreateWindow("Title %s", a);
That's what your fine with, that's what the DIP your wrote
would allow.
It's like you are just reading what you want to, instead of
actually understanding what people are saying. I'd have more
luck talking to a brick wall at the rate this thread is going,
jesus.
Come on, this isn't Reddit. Be more civil.
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 17:11:18 UTC, bachmeier wrote: There needs to be a variant of "mansplaining" modified for Python users. Agreed, and there also needs to be a variant of prison, modified for people who post dumb comments on Hacker News.
Re: Release D 2.090.0
On Wednesday, 8 January 2020 at 21:58:29 UTC, H. S. Teoh wrote: On Wed, Jan 08, 2020 at 09:43:05PM +, Meta via Digitalmars-d-announce wrote: [...] Deprecated module std.experimental.all was removed All symbols contained in Phobos can now be used with import std Maybe I'm wrong, but this seems like a bad idea to me (unless we're getting rid of std.experimental). I think you misunderstood what happened here. Originally std.experimental.all *was* the same thing as today's std/package.d; the only reason it was put in std.experimental was because it was still an experiment to see if importing all of Phobos is actually feasible in practice. Since it apparently worked quite well, it was moved from std/experimental/all.d to std/package.d. Ergo, import std.experimental.all != import std.experimental.*; rather, import std.experimental.all == import std.* in the past, and now we've just made it official by allowing you to write: import std; T Ah, I misunderstood. Thanks.
Re: Release D 2.090.0
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote: Glad to announce D 2.090.0, ♥ to the 48 contributors. This release comes with the ability to convert lazy parameters to delegates, new intrinsics to force rounding to specific floating point precision, unittest builds that no longer execute main by default, a new GC.inFinalizer API, and various other changes. http://dlang.org/download.html http://dlang.org/changelog/2.090.0.html -Martin Deprecated module std.experimental.all was removed All symbols contained in Phobos can now be used with import std Maybe I'm wrong, but this seems like a bad idea to me (unless we're getting rid of std.experimental).
Re: `in` parameters optimization
On Wednesday, 25 December 2019 at 01:24:52 UTC, Adnan wrote: Does the compiler automatically pass values by reference if possible with `in` parameters in higher level of optimization flags? I would normally use `in ref` but sometimes it's not compatible with different types. No. "in" is short for "const scope" (https://dlang.org/spec/function.html#param-storage). The only mechanism D has for expressing "pass this argument by ref if possible, and by value otherwise" is "auto ref" (https://dlang.org/spec/function.html#auto-ref-functions), which requires your function to be templated.
Re: Using map result type
On Wednesday, 11 December 2019 at 20:08:37 UTC, Meta wrote:
import std.algorithm;
import std.range;
void mapAccepter(E)(InputRange!E r)
{
import std.array: array;
import std.stdio: writeln;
auto collected = r.array;
writeln(collected);
}
void main()
{
int[] nums = [1, 2, 3];
auto evenness = inputRangeObject(map!(n => n % 2 ==
0)(nums));
mapAccepter(evenness);
}
I guess I should mention, that if you are expecting a range of
booleans, you can of course write mapAccepter as a non-templated
function:
void mapAccepter(InputRange!bool r);
But if you want to support any type of input range, the function
needs to at least be templated on the element type of the range.
Re: Using map result type
On Sunday, 8 December 2019 at 01:10:21 UTC, AA wrote:
I'd like to accept the return type of map. From some previous
questions that I should accept a template?
So for something like:
```
void mapAccepter(Range)(Range r)
{
import std.array : array;
import std.stdio : writeln;
auto collected = r.array;
writeln(collected);
}
void main()
{
import std.algorithm.iteration : map;
int[] nums = [1, 2, 3];
auto evenness = map!(n => n % 2 == 0)(nums);
mapAccepter(evenness);
}
```
1) Is there any way I can make `mapAccepter` not a templated
function?
Yes (mostly, anyway), using the interfaces in
std.range.interfaces:
https://dlang.org/phobos/std_range_interfaces.html
import std.algorithm;
import std.range;
void mapAccepter(E)(InputRange!E r)
{
import std.array: array;
import std.stdio: writeln;
auto collected = r.array;
writeln(collected);
}
void main()
{
int[] nums = [1, 2, 3];
auto evenness = inputRangeObject(map!(n => n % 2 == 0)(nums));
mapAccepter(evenness);
}
`mapAccepter` still needs to be templated on the element type of
the range,
but there are ways to avoid that as well, if desired. I wouldn't
recommend it,
however, as it wouldn't be that useful in this case.
2) Is there any way if I need to make `mapAccepter` templated
to constrain Range to be a range of booleans.
Yup, there are two ways that you you primarily do that. Either
constraining E in the template declaration, or adding a constraint
on the template. Generally option 2 is the more idiomatic D way.
Option 1: constrain E to be of type bool:
void mapAccepter(E: bool)(InputRange!E r);
OR
void mapAccepter(E)(InputRange!E r)
if (is(E == bool));
There's not much difference between these two, but the latter is
probably preferred.
Option 2: use std.traits and a template constraint:
void mapAccepter(E)(InputRange!E r)
if (is(ElementType!r == bool));
Re: Unexpectedly nice case of auto return type
On Tuesday, 3 December 2019 at 22:11:39 UTC, Meta wrote: On Tuesday, 3 December 2019 at 17:45:27 UTC, H. S. Teoh wrote: The thing is, `void` means "no return type" (or "no type" in some contexts), i.e., void == TBottom in that case. Not *quite* correct. void is not a bottom type; it's a unit type, meaning that it's a type with only 1 value (as is null, interestingly). void does not mean "no return type"; it means "there's only 1 possible value that can be returned". A function returning TBottom means that the function will never return, e.g., it loops forever, or throws an exception, etc. Whoops, skimmed over the post already mentioning this.
Re: Unexpectedly nice case of auto return type
On Tuesday, 3 December 2019 at 17:45:27 UTC, H. S. Teoh wrote: The thing is, `void` means "no return type" (or "no type" in some contexts), i.e., void == TBottom in that case. Not *quite* correct. void is not a bottom type; it's a unit type, meaning that it's a type with only 1 value (as is null, interestingly). void does not mean "no return type"; it means "there's only 1 possible value that can be returned". A function returning TBottom means that the function will never return, e.g., it loops forever, or throws an exception, etc. I agree with the OP that it's silly not to give typeof(null) a name. As null is a unit type, we could easily have `null` stand in for typeof(null) as well. A type that contains only one value can be synonymous with that value (see also, Rust's unit type (), which has one value, ()).
Re: interfaces and contracts - new pattern
On Tuesday, 3 December 2019 at 17:10:04 UTC, Meta wrote: On Monday, 2 December 2019 at 20:30:49 UTC, Adam D. Ruppe wrote: In short use `in(false)` when you `override` a function to inherit the contract, unless you explicitly want to expand the input - which you shouldn't do when implementing an interface! Wrote about it in more details here: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through. destroy if i missed anything lol I thought this was a defect that was fixed a long time ago, where if the overriding function has no contract, it is implicitly given a "in (true)" contract, causing the contract of the overridden function to not be run. Am I mistaken as to what the defect was, or as to whether it was fixed, or both? I think this is the defect in question: https://issues.dlang.org/show_bug.cgi?id=6856 I see a PR in comment 35: https://github.com/dlang/dmd/pull/4200 But it was closed. However, Iain Buclaw created a successor to 4200: https://github.com/dlang/dmd/pull/7510 Which is still open, but Iain ran into stack corruption issues when compiling with the -m64 flag... and no further progress. So I guess it's just a matter of the bug not being fixed.
Re: interfaces and contracts - new pattern
On Monday, 2 December 2019 at 20:30:49 UTC, Adam D. Ruppe wrote: In short use `in(false)` when you `override` a function to inherit the contract, unless you explicitly want to expand the input - which you shouldn't do when implementing an interface! Wrote about it in more details here: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through. destroy if i missed anything lol I thought this was a defect that was fixed a long time ago, where if the overriding function has no contract, it is implicitly given a "in (true)" contract, causing the contract of the overridden function to not be run. Am I mistaken as to what the defect was, or as to whether it was fixed, or both?
Re: Alternative to C++ macro in D
On Sunday, 3 November 2019 at 16:55:36 UTC, Vinod K Chandran
wrote:
Hi all,
I can do this in C++. #include
using namespace std ;
#define end };
#define log(x) cout << x << endl
#define wait std::cin.get()
int main() {
log("Trying to avoid the visual clutter aused by closing
curly braces") ;
string myStr = "Now, code looks more elegant" ;
log(myStr) ; mixin template cToD(string code)
`log` and `wait` are straightforward. Just write a function:
import std.stdio;
void log(T)(T x) { writeln(x); }
void wait() { readln(); }
However, you can't do things like `#define end }`. The D language
intentionally disallows doing stuff like this. If you *really*
want to do this, you can sort of emulate it with mixins:
mixin template cToD(string code)
{
import std.array: replace;
mixin(code.replace("end", "}"));
}
mixin cToD!`
int main() {
log("Trying to avoid the visual clutter aused by closing
curly braces") ;
string myStr = "Now, code looks more elegant" ;
log(myStr) ;
wait ;
return 0;
end
`;
But I would strongly recommend against it.
Re: D code running on the Nintendo 3DS
On Sunday, 20 October 2019 at 06:06:48 UTC, TheGag96 wrote: Hi, all. I wanted to get into the world of 3DS homebrew, but I really didn't feel like coding in C or C++. So, through an effort of sheer will, I somehow got a hello world example written in D up and running, along with bindings for most of libctru and citro3d. https://github.com/TheGag96/3ds-hello-dlang Included are instructions on how to set this up (although it's pretty hacky). I imagine one could easily start writing Switch homebrew in D by following most of these steps as well. Once GCC 10 comes out with an updated GDC, it might become a pretty attractive alternative to C/++ for such projects if some work is put into bindings and stuff. Hope someone finds this interesting! Awesome work. I used to hack around on my original NDS and thought about maybe trying to get D working on it, but didn't have sufficient time or motivation. I'll definitely play around with this.
Re: Átila's Vision of D's Future
On Wednesday, 16 October 2019 at 09:46:49 UTC, aliak wrote: It's better to link straight to an item on hackernews as links on the front page disappear very fast. https://news.ycombinator.com/item?id=21257943 Cheers, - Ali HN has this (IMO) ridiculous policy of going to great lengths to prevent upvotes from people following a direct link to the post.
Re: Blog Post: Beating std::visit Without Really Trying
On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote: I was curious how C++17's std::variant compared to the options we have in D, like Algebraic and SumType, so I did a simple comparison of the generated assembly for each of them. You can read about it at the link below. And as you can probably guess from the title, D comes out ahead, in the end. https://pbackus.github.io/blog/beating-stdvisit-without-really-trying.html This is my first attempt at sharing something like this, so any comment or feedback is very much appreciated! I'm not sure if you're aware, but funnily enough, I also wrote an article[1] on std::variant vs. the D alternative that references Matt Kline's article on std::visit. It seems we're really making getting our money's worth from his article. I really enjoyed this - I think you're right in that it comes down to the complexity of implementation, and I suspect that C++ forced the developers of std::variant to choose between a usable API (usable, not good) and performance. I've been trying to communicate this major selling point of D to my coworkers, but it's a real uphill battle. I haven't even been able to convince them that built-in unit tests are a killer feature. As an aside, I actively use your sumtype library and for the most part find it very nice to use. Thanks for the great work. 1.https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/
Re: SAOC Experience Report: Porting a fork-based GC
On Monday, 22 July 2019 at 14:03:15 UTC, Mike Parker wrote: Francesco Mecca ha written an experience report for the D Blog about his SAOC 2018 project, porting Leandro Lucarella's old GC from D1 to D2. The blog: https://dlang.org/blog/wp-admin/post.php?post=2148=edit Reddit: > https://www.reddit.com/r/programming/comments/cgdk1r/symmetry_autumn_of_code_experience_report_porting/ A pull request to the D runtime was my final milestone. I was ready at the beginning of February, but I started to procrastinate. I’d had no previous communication with any of the reviewers and I was timorous about engaging with them. I spent a lot of time refactoring my code back and forth and delaying my pull request. At a certain point, I even considered abandoning the final milestone and providing the GC as a library. In the meantime, Rainer Scheutze published a threaded implementation of the mark phase that reduced the mark time in the GC and I lost faith in my project. This seems like a major failure in the process that this was allowed to happen - good work almost went abandoned. How can we prevent this in future SAoC/GSoC? Without knowing what the mentor did/didn't do, an obvious answer seems like there should be a follow-up to ensure that the work done is actually getting in to the compiler/runtime/etc. To go so far and trip right at the finish line is unfortunate (glad to see that a PR is now open).
Re: UPB D Summer School
On Wednesday, 17 July 2019 at 13:56:38 UTC, RazvanN wrote: Hello, Edi and myself are glad to announce that the first edition of the D Summer School that we organized for the students at the University Politehnica of Bucharest has just ended. We had 8 practical sessions and a hackathon, during which students had to work on their project a peer-to-peer client implementation using vibe.d). The students were lucky enough to actually have Andrei present them the "Design by Introspection" course. It goes without saying that they were thrilled. Our materials can be found here [1] if anybody is interested ( big thanks to Ali for his approval on basing our course on his book). Photos from the hackathon and Andrei's lecture can be found here [2]. We hope that by bringing D bootcamp courses to students we can raise awarness on D and increase its popularity and enlarge our community. We have encouraged the graduating students to participate to SAOC and also we are in discussions with some of them to initiate them into contributing to D. Cheers, RazvanN [1] https://ocw.cs.pub.ro/courses/dss/ [2] https://photos.google.com/share/AF1QipMRoQCmOcPh4E9nvn4hL4gGXeebPDYV9lSlH8lMhaZJmL4z6lt6QcCNs8iFvPkmxw?key=WUU3eXY3T05vR09HZlQ3X3ZBTXdidTBNQ3YzU01n That's awesome! Did the students earn actual credit hours for this bootcamp, or was it more interest-based?
Re: Elegant way to test if members of array A are present in array B?
On Tuesday, 11 June 2019 at 17:12:17 UTC, Robert M. Münch wrote: Is there a simple and elegant way to do this? Or is just using a foreach(...) with canFind() the best way? There are two versions of find that can find a range within another: https://dlang.org/phobos/std_algorithm_searching.html#.find https://dlang.org/phobos/std_algorithm_searching.html#.find.3
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote:
On 24.05.19 18:19, Atila Neves wrote:
On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote:
[...]
My `puts`s might not do any harm, but they could just as well
be buffer overflows.
Could you please give an example of how @system allocator code
could do that?
Sure. You just write beyond some buffer instead of calling
`puts`:
char[3] buf;
char[3] foo = "foo";
char[3] bar = "bar";
struct UnsafeAllocator
{
import std.experimental.allocator.mallocator: Mallocator;
static instance = UnsafeAllocator.init;
size_t i;
void deallocate(void[] bytes) @nogc @system
{
buf.ptr[i .. i + 3] = '!';
Mallocator.instance.deallocate(bytes);
}
void[] allocate(size_t sz) @nogc @system
{
buf.ptr[i .. i + 3] = '!';
return Mallocator.instance.allocate(sz);
}
}
void main() @safe @nogc
{
{
import nogc: BUFFER_SIZE, text;
UnsafeAllocator.instance.i = 8;
/* greater than buf.length, whoops */
auto t = text!(BUFFER_SIZE, UnsafeAllocator)(42);
assert(foo == "foo"); /* fails */
UnsafeAllocator.instance.i = 16;
/* also greater than buf.length, whoops again */
}
assert(bar == "bar"); /* fails */
}
You just can't trust user-provided @system code. It doesn't
matter if it's allocator code or whatever.
That's right. If you are wrapping code that is provided by a
third party, you should not mark any code as @trusted that makes
calls to the third party library. By doing this, you are saying
"any third party code I call is memory safe (source: dude just
trust me)". That may work in the case where this third party code
is set in stone and has been hand-audited by either you or the
maintainers (ideally both), but you're accepting any
implementation through a template argument. Doing this is
extremely dangerous, because you're making memory safety promises
about every single Allocator implementation in existence, in the
present AND for the future.
What you have to do is leave the functions that make these calls
unmarked (no @system, @trusted OR @safe), and allow the compiler
to infer it based on the whether the third party implementation
is @system/@trusted/@safe. That's the only sane way I can think
of to do this.
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 21:57:51 UTC, Meta wrote: I see what you're getting at. The compiler sees a slice type (i.e., Data[]), knows that it's GC-backed and thus has infinite lifetime, and concludes "the data you're trying to put in the store has too long of a lifetime". Should be "too _short_".
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 18:45:12 UTC, Jonathan M Davis wrote: On Friday, May 17, 2019 11:25:40 AM MDT Meta via Digitalmars-d-announce wrote: I don't want to *restrict* the lifetime of a heap allocation. I want the compiler to recognize that the lifetime of my original data is the same as the processed output, and thus allow my code to compile. It is my understanding that DIP 1000 really doesn't track lifetimes at all. Then why does the DIP, in addition to many of the error messages, use the word lifetime? I feel like I know less about DIP1000 and what it actually does than when I started. Can someone _please_ point me at any up to date documentation on this?
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 20:59:43 UTC, Mike Franklin wrote: On Friday, 17 May 2019 at 17:03:51 UTC, Meta wrote: If you look at `main` above, `rawData` has the same lifetime as the `dataRange` struct returned from `makeDataRange` and the queue returned from `copyToQueue`. True, there is some traditionally unsafe stuff happening in between; however, I thought that the point of adding all these annotations is to tell the compiler how the lifetimes of these objects propagate up and down the call stack, so that it can check that there will be no memory corruption. I'm not doing anything here that will result in a pointer to an expired stack frame, or otherwise cause memory corruption or use after free, or anything like that (*unless* I allow either `dataRange` or `result` to escape from the main function - which dip1000 correctly disallows). I don't think it does because `Queue!(T).store` has infinite lifetime beyond that of even `main`, at least as far as the compiler is concerned. I see what you're getting at. The compiler sees a slice type (i.e., Data[]), knows that it's GC-backed and thus has infinite lifetime, and concludes "the data you're trying to put in the store has too long of a lifetime". That makes sense, but slices don't necessarily have to be backed by the GC, so that seems like a faulty heuristic to me and possibly a vector for bugs. The compiler doesn't have enough information to know that `store` is tied to the lifetime of `Queue!(T)` (a.k.a `rawData`) and maybe that's a missing language feature. According to the DIP, "from a lifetime analysis viewpoint, a struct is considered a juxtaposition of its direct members." Who knows if that's still the case, because Walter has considerably changed how it works but has not documented those changes (IIRC, I may be wrong on that). That probably means that a Queue!T has an infinite lifetime, assuming that the compiler sees its T[] member as having an infinite lifetime. Maybe we should be allowed to declare aggregate fields as `scope` to convey that, but the compiler currently disallows it. That might be nice but would also probably cause a dramatic increase in complexity. I haven't thought through the possible ramifications of making a change like that.
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 05:27:02 UTC, Walter Bright wrote: On 5/16/2019 9:50 PM, Meta wrote: Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you. https://forum.dlang.org/post/laqjadtwrsdhdrqok...@forum.dlang.org As always, I recommend drastically reducing the example. It nearly always makes the actual problem emerge from all the noise. I'll try to reduce it further, but this example is already as reduced as I could make it while still having the same structure as my actual code.
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 17:05:21 UTC, ag0aep6g wrote: On 17.05.19 14:10, Meta wrote: Your explanation was fine, but I need a good solution, other than wrapping the array assignment in @trusted. I see. As far as I understand DIP 1000, it's not supposed to enable your use case without having to use `@trusted`. If this is true, then I have a big problem with DIP1000. This is an extremely common use case (copying memory from an inner scope with a limited lifetime to some store in an outer scope with a longer or infinite lifetime). DIP 1000 stops at heap allocations. It just assumes infinite lifetime for them. Yes, as per the DIP. If you want to restrict the lifetime of a heap allocation (in your case: tie it to the lifetime of a struct), you have to do it manually. I don't want to *restrict* the lifetime of a heap allocation. I want the compiler to recognize that the lifetime of my original data is the same as the processed output, and thus allow my code to compile.
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 05:32:42 UTC, Mike Franklin wrote:
On Friday, 17 May 2019 at 05:22:30 UTC, Mike Franklin wrote:
My assessment (which could be wrong):
`scope` and `return` only apply to pointers and `ref`s. If
you remove all `scope` and `return` attributes from the
function `push`, it works fine.
I consider it a bug that the compiler doesn't emit an error
when using attributes on types for which they are not intended.
Mike
Working example: https://run.dlang.io/is/TCP0td
That does compile, but I don't think that it's working the way I
want it to. I believe it only works because a GC-managed string
is used for the backing storage. If you change that to a static
array on the stack:
@safe
void main()
{
immutable(char)[16] rawData = "2 6 4 1 0 2 9 4 5";
auto dataRange = makeDataRange(rawData);
auto result = dataRange.copyToQueue();
import std.stdio;
writeln("The result of data processing is: ", result);
}
It will refuse to compile with this message:
Error: reference to local variable rawData assigned to non-scope
parameter input calling makeDataRange
`makeDataRange` is defined like this:
@safe
DataRange makeDataRange(string input)
{
auto range = DataRange(input);
return range;
}
So that static array is getting implicitly sliced, i.e., its
address is being taken. It's pretty obvious why `input` is not
being inferred as scope - it's being returned from
`makeDataRange`. However, when I try to manually annotate it with
return or return scope, I run into further errors:
DataRange makeDataRange(return scope string input)
{ ...etc. }
Error: scope variable input assigned to non-scope parameter
rawData calling DataRange.this
Error: scope variable dataRange assigned to non-scope parameter
data calling copyToQueue
So I continue annotating things with scope or return or return
scope whenever the compiler complains about it, going up through
the call chain until I arrive back at my original problem
mentioned in the post I linked.
(My original example with changes made going through this
exercise: https://run.dlang.io/is/uQDXG6)
This is why I say that I'm not sure that I quite understand
dip1000. I *thought* I did, but an example that seems like it
should clearly work (at least to me), does not.
If you look at `main` above, `rawData` has the same lifetime as
the `dataRange` struct returned from `makeDataRange` and the
queue returned from `copyToQueue`. True, there is some
traditionally unsafe stuff happening in between; however, I
thought that the point of adding all these annotations is to tell
the compiler how the lifetimes of these objects propagate up and
down the call stack, so that it can check that there will be no
memory corruption. I'm not doing anything here that will result
in a pointer to an expired stack frame, or otherwise cause memory
corruption or use after free, or anything like that (*unless* I
allow either `dataRange` or `result` to escape from the main
function - which dip1000 correctly disallows).
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 05:22:31 UTC, ag0aep6g wrote: On 17.05.19 06:50, Meta wrote: Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you. https://forum.dlang.org/post/laqjadtwrsdhdrqok...@forum.dlang.org You don't like my explanation? https://forum.dlang.org/post/q6r4bf$2hu4$1...@digitalmars.com (same thread) Your explanation was fine, but I need a good solution, other than wrapping the array assignment in @trusted.
Re: Phobos is now compiled with -preview=dip1000
On Wednesday, 15 May 2019 at 08:32:09 UTC, Walter Bright wrote: On 5/15/2019 12:21 AM, Dukc wrote: Could be worth a try even without docs, but in the long run we definitely need some explaining. True, but I've tried fairly hard with the error messages. Please post your experiences with them. Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you. https://forum.dlang.org/post/laqjadtwrsdhdrqok...@forum.dlang.org
Re: DMD metaprogramming enhancement
On Friday, 26 April 2019 at 06:34:26 UTC, Simen Kjærås wrote: BTW, at least two people have promised money outside BountySource to have 5710 fixed: https://forum.dlang.org/post/gjzrklkxfmgjjdfor...@forum.dlang.org -- Simen And my offer still stands. Suleyman, do you have an email address I can contact you at to arrange payment?
Re: How to debug long-lived D program memory usage?
On Wednesday, 17 April 2019 at 22:37:38 UTC, Adam D. Ruppe wrote: On Wednesday, 17 April 2019 at 19:07:46 UTC, Jacob Carlborg wrote: Perhaps try some of these flags [1] and [2]. oooh, those are very interesting too. What I was kinda hoping is it would have stats for which file and line of code was responsible for most allocations; a detailed profile. But even so, this is an interesting gem. Not at all what you want, but it may be useful for figuring out where the leaks are. Have you tried compiling with -vgc? https://dlang.org/dmd-windows.html#switch-vgc
Re: Phobos now compiling with -dip1000
On Saturday, 23 March 2019 at 05:04:58 UTC, H. S. Teoh wrote: Also, does it only apply to @safe code, so that I have to start annotating stuff with @safe in order to benefit from it? T As per the DIP and from my experience, yes.
Re: Block statements and memory management
On Saturday, 16 March 2019 at 03:47:43 UTC, Murilo wrote:
Does anyone know if when I create a variable inside a scope as
in
{int a = 10;}
it disappears complete from the memory when the scope finishes?
Or does it remain in some part of the memory? I am thinking of
using scopes to make optimized programs that consume less
memory.
I'd recommend against these sorts of micro-optimizations.
Compilers are every good at doing this kind of thing manually so
you don't have to worry about it and can concentrate on the
actual logic of your program.
Re: Containerize Your D Server Application
On Friday, 15 March 2019 at 04:43:21 UTC, Nick Sabalausky (Abscissa) wrote: On 3/14/19 8:38 AM, Mike Parker wrote: One of the items on my list of "things I'd like to do if I only had the time" is to create a Mud server with D and deploy it with Docker. Just for kicks. If I ever do get around to it, my ignorance of all things Docker will not be the time sink it could have been thanks to this latest post on the D Blog by Kai Nacke. The Blog https://dlang.org/blog/2019/03/14/containerize-your-d-server-application/ Reddit https://www.reddit.com/r/programming/comments/b0zqck/containerize_your_d_server_application/ Interestingly, this appears to be by far the best introduction to docker I've ever come across - and that's *including* docker's own vacuous website. Agreed; it's a good starter tutorial to familiarize someone with the basics. Great article Kai!
Re: Containerize Your D Server Application
On Thursday, 14 March 2019 at 18:02:31 UTC, Arun Chandrasekaran wrote: On Thursday, 14 March 2019 at 12:38:30 UTC, Mike Parker wrote: One of the items on my list of "things I'd like to do if I only had the time" is to create a Mud server with D and deploy it with Docker. Just for kicks. If I ever do get around to it, my ignorance of all things Docker will not be the time sink it could have been thanks to this latest post on the D Blog by Kai Nacke. The Blog https://dlang.org/blog/2019/03/14/containerize-your-d-server-application/ Reddit https://www.reddit.com/r/programming/comments/b0zqck/containerize_your_d_server_application/ Can we make dub generate the docker container as well? CMake can do that. The usage would be simply ``` dub build -b release dub build docker Couldn't you use `postBuildCommands` for that? https://dub.pm/package-format-json.html#build-settings
Re: Query for -dip1000
On Sunday, 10 February 2019 at 20:04:29 UTC, Per Nordlöw wrote:
Is there a way to query if the -dip1000 flag has been passed to
the compiler? I need it for enabling certain DIP-1000 escape
analysis tests only when -dip1000 has been passed.
For instance
static assert(!__traits(compiles, {
char[] f()
{
char[2] x;
return x[].splitterASCII!(_ => _ == '
').front;
}
}));
at
https://github.com/nordlow/phobos-next/blob/bd2fe42978aab2313977042c858d77c5766538e8/src/splitter_ex.d#L110
Or do I have to write a trait myself?
https://issues.dlang.org/show_bug.cgi?id=19669
Re: Implement Interface Using Super
On Wednesday, 30 January 2019 at 01:02:37 UTC, Jonathan M Davis
wrote:
Yeah. It would be like trying to do something like
alias x = this.x;
As it stands, I believe that super is always either used as a
function call to the constructor or to mean the this pointer
for the base class. I don't think that it ever means the type
of the base class - just like this never means the type of the
current class or struct. And their usage is pretty much
identical. They're both either used for calling a constructor
or for accessing the pointer/reference of the object. It's just
that one of them is for the current class or struct, whereas
the other is for a base class of the current class. The only
difference in syntax that I can think of between them at the
moment is that this is also used to name constructors when
they're declared, whereas super is not used in that sort of way
(since any constructor that would be referenced by super would
be declared with this, not super).
- Jonathan M Davis
Current, you *can* use `super` to mean the type of the base
class, but it's been deprecated in a recent release (IIRC):
class Super
{
}
class Sub
{
super test()
{
return new Super();
}
}
void main()
{
(new Sub()).test();
}
From DPaste:
Up to 2.080.1: Success and no output
Since 2.081.2: Success with output: onlineapp.d(7):
Deprecation: Using `super` as a type is deprecated. Use
`typeof(super)` instead
Re: Implement Interface Using Super
On Monday, 28 January 2019 at 22:17:56 UTC, Steven Schveighoffer wrote: On 1/28/19 3:28 PM, Jonathan Levi wrote: On Sunday, 27 January 2019 at 09:31:46 UTC, bauss wrote: On Sunday, 27 January 2019 at 05:37:57 UTC, Jonathan Levi wrote: This works in LDC *but not* DMD? . . . Is this a bug in DMD *or* in LDC? There is no bug here. So... LDC is the one that is bugged? Yeah, that's odd. It should be the same result, as they both have the same semantics for the front end. I'll defer to an LDC developer to answer that, but in truth, it really should be the way LDC implements it, even if that's not how the language spec is. I think it would have been nice to have a way of explicitly use the super method to implement an interface without having to rewrite the whole signature. I thought I remember seeing a way once, but I must have been dreaming. I agree. BTW, the typeof(super) requirement is super-annoying. alias x = super.x; is clear, I don't see why we need to specify typeof(super) in this context at least. -Steev It's because aliases do not support context pointers, I'm pretty sure.
Re: New Fundraiser: D Forums Server
On Friday, 25 January 2019 at 19:14:31 UTC, Mike Parker wrote: On Friday, 25 January 2019 at 19:11:59 UTC, Mike Parker wrote: Flipcause donors are not American. Did you have trouble? If so, you can go to the donation page and use the PayPal link. Sorry: https://dlang.org/foundation/donate.html For anyone else donating via Paypal, it didn't go through the first two times and just spit out some generic error message (using Paypal One Touch; not sure if that matters). If you get an error when trying to donate through the link on the donation page, just keep trying until it succeeds. Only the successful payment will actually be charged to your Paypal account, so there's no worry of making multiple payments by mistake.
Re: D-lighted, I'm Sure
On Saturday, 19 January 2019 at 22:09:57 UTC, Ron Tarrant wrote: On Friday, 18 January 2019 at 19:55:34 UTC, Meta wrote: Great read Ron. Can I ask which town in Newfoundland it was where you stayed back in 1985? Sure. I was in St. Lawrence on the Burin Peninsula. Do you know it? Unfortunately (or fortunately?) not. I've spent a good deal of time exploring the western side of NFLD but have only visited Gander and St. John's on the eastern side.
Re: D-lighted, I'm Sure
On Friday, 18 January 2019 at 16:42:15 UTC, Ron Tarrant wrote: Just to set the record straight, I only had access to that Coleco Adam for the few weeks I was in that Newfoundland outport. Within a year, I too had my very own C-64 plugged into a monster Zenith console job. Remember those? I don't remember what I paid for a used C-64, but the Zenith 26" was $5 at a garage sale up the street and another $5 for delivery. Great read Ron. Can I ask which town in Newfoundland it was where you stayed back in 1985?
Re: Top Five World’s Most Underrated Programming Languages
On Friday, 18 January 2019 at 01:15:06 UTC, Bill Baxter wrote: Gotta laugh at Ruby being listed as "Underrated", though. --bb On Mon, Jan 14, 2019 at 12:25 PM Andrei Alexandrescu via Digitalmars-d-announce wrote: Of possible interest: https://www.technotification.com/2019/01/most-underrated-programming-languages.html I get the feeling that Ruby's popularity is waning with the rise of Node.js and the broad ecosystem of Javascript-based web application frameworks. At one time it probably came close to rivaling Python in popularity and sheer volume of new development, but I think that's firmly in the past now (not that it is dead, by any means).
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Thursday, 17 January 2019 at 01:59:29 UTC, Walter Bright wrote: Bartosz Milewski is a C++ programmer and a Haskell fan. He once gave a presentation at NWCPP where he wrote a few lines of Haskell code. Then, he showed the same code written using C++ template metaprogramming. The Haskell bits in the C++ code were highlighted in red. It was like a sea of grass with a shrubbery here and there. Interestingly, by comparing the red dots in the C++ code with the Haskell code, you could understand what the C++ was doing. Without the red highlighting, it was a hopeless wall of < > :-) Since I mention Bartosz, I should link to his blog: https://bartoszmilewski.com/ It was an article on Bartosz's blog where I first found out about D. I think this was the first one: "The more things change, the more we need “immutable”" https://bartoszmilewski.com/2009/01/
Re: The New Fundraising Campaign
On Friday, 4 January 2019 at 16:21:16 UTC, Mike Parker wrote: On Friday, 4 January 2019 at 15:43:41 UTC, Meta wrote: Awesome; funding goal reached in a little less than 2 months. I didn't even get around to donating yet, so maybe I'll save it for the next one instead. On a related note, D really needs a merch shop. I don't think I'm the only one that wants a shirt or mug with (a|the) D logo on it, or Dman. There's an entire industry that's popped up to make paraphernalia sales far easier in the wake of Youtube/Deviantart/etc. which is geared toward community-based projects similar to D. It's coming. Can't wait!
Re: The New Fundraising Campaign
On Friday, 4 January 2019 at 10:30:07 UTC, Martin Tschierschke wrote: On Saturday, 10 November 2018 at 16:09:12 UTC, Mike Parker wrote: [...] Please read the blog post for more details: https://dlang.org/blog/2018/11/10/the-new-fundraising-campaign/ https://www.flipcause.com/secure/cause_pdetails/NDUwNTY= $3,014 Raised of $3,000 Goal 41 days left 51 Supporters Cool, what a wonderful start to the year 2019! A big thank you to all pushing the development of D with money and time! What next Mike? Awesome; funding goal reached in a little less than 2 months. I didn't even get around to donating yet, so maybe I'll save it for the next one instead. On a related note, D really needs a merch shop. I don't think I'm the only one that wants a shirt or mug with (a|the) D logo on it, or Dman. There's an entire industry that's popped up to make paraphernalia sales far easier in the wake of Youtube/Deviantart/etc. which is geared toward community-based projects similar to D.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 20:44:28 UTC, Dukc wrote: On Tuesday, 11 December 2018 at 15:34:28 UTC, Simen Kjærås wrote: I believe a reasonable case can be made for .! for UFCS - it's currently invalid syntax and will not compile, and ! is the symbol we already associate with template instantiation: alias memberFunctions = __traits(allMembers, T) .!staticMap!Member .!Filter!(isSomeFunction); -- Simen Perhaps. I also think that it might be good if types could be results of compile-ime expressions, including ufcs expressions (so that 42.typeof would become legal, meaning an int). I vaguely remember a very ancient version of D that had .typeof instead of typeof(). This might've been D1... the details are fuzzy.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Template lambdas and better eponymous template syntax are the two big ones that I would really like. It's very painful not having them in code that makes heavy use of metaprogramming.
Re: Copy Constructor DIP and implementation
On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis wrote: @implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist. - Jonathan M Davis I somewhat agree with this argument, but overall I hate this attitude of "we should just make the change because it *probably* won't break any code", and then bonus points for "code that does this is wrong anyway so we shouldn't care if we break it". I've already been burned by that a couple times using D, and I imagine heavy corporate users with large code bases have many more problems with this.
Re: Rather D1 then D2
On Monday, 24 September 2018 at 09:19:34 UTC, Chris wrote: On Sunday, 23 September 2018 at 02:05:42 UTC, Jonathan M Davis wrote: With regards to D1 users who are unhappy with D2, I think that it makes some sense to point out that a subset of D2 can be used in a way that's a lot like D1, but ultimately, if someone doesn't like the direction that D2 took, they're probably better off finding a language that better fits whatever it is that they're looking for in a language. Trying to convince someone to use a language that they don't like is likely to just make them unhappy. - Jonathan M Davis Maybe it's time for D3. Pick and choose the things that work and really do make sense and discard others that don't add much value but only bring trouble. I think D2 is a nice collection of Lego bricks by now that could be used to build something truly great. I don't agree; the time for D3 is still many years away. Transitiong to D3 now would be suboptimal, as the D2 language is still being "explored". The D community as a whole needs more experience with the language to understand pain points, so we can make more informed changes in D3 (if D3 ever happens; it may not need to).
Re: Copy Constructor DIP and implementation
On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote: Hello everyone, I have finished writing the last details of the copy constructor DIP[1] and also I have published the first implementation [2]. As I wrongfully made a PR for the DIP queue in the early stages of the development of the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it! Thanks, RazvanN [1] https://github.com/dlang/DIPs/pull/129 [2] https://github.com/dlang/dmd/pull/8688 If @implicit is the contentious part of this DIP, maybe it would be a good idea for us to instead use a `pragma(copyCtor)` or the like to avoid having to add another attribute while preserving backward-compatibility. Like @implicit, it's very easy to turn existing constructors into copy constructors just by adding the pragma, and they can be added to code with impunity because even older versions of the compiler will just ignore pragmas they don't recognize.
Re: John Regehr on "Use of Assertions"
On Monday, 10 September 2018 at 20:25:21 UTC, Jonathan M Davis wrote: I propose: - 'assume': aborts on false condition in debug builds, not checked in release builds, used as optimizer hint; - 'insist': aborts on false condition in debug builds, aborts on false condition in release builds, used as optimizer hint; - 'uphold': aborts on false condition in debug builds, aborts on false condition in release builds, NOT used as optimizer hint; - 'allege': logs error and aborts on false condition in debug builds, logs error and continues on false condition in release builds, NOT used as optimizer hint; Honestly, that seems like total overkill I'm pretty sure that was sarcasm on H. S. Teoh's part. Of course, I can't tell for sure due to Poe's Law.
Re: Small @nogc experience report
On Friday, 7 September 2018 at 17:35:12 UTC, Eugene Wissner wrote:
On Friday, 7 September 2018 at 17:01:09 UTC, Meta wrote:
Semi-unrelated, but I think you should open a bug for this
one. I remember Andrei stating before that every function in
std.algorithm except for LevehnsteinDistance(?) is @nogc, so
he either missed topNCopy or the gc-ness of the function has
changed sometime between ~2015 and now.
It was never true. Here is another example:
import std.algorithm;
void main() @nogc
{
int[4] a, b;
fill(a[], b[]);
}
The funny thing is that fill() doesn't always allocate, but
only if the element to fill with, is an array. fill() uses
enforce() which allocates and throws. Other algorithms (e.g.
equal) have special handling for character arrays and throw if
they get wrong unicode or use some auto-decoding functions that
aren't @nogc.
I'm sure I've heard Andrei mention it multiple times, but I must
be misremembering something.
