Re: Bug or feature? iota has different semantics for integer and float arguments
On Saturday, 7 January 2023 at 02:31:14 UTC, Ali Çehreli wrote: On 1/6/23 17:50, Arredondo wrote: > Would anyone volunteer to file a bug report? Me! Me! :) https://issues.dlang.org/show_bug.cgi?id=23604 Ali Thanks a lot :D Arredondo.
Re: Bug or feature? iota has different semantics for integer and float arguments
On 1/6/23 17:50, Arredondo wrote: > Would anyone volunteer to file a bug report? Me! Me! :) https://issues.dlang.org/show_bug.cgi?id=23604 Ali
Re: Bug or feature? iota has different semantics for integer and float arguments
On Saturday, 7 January 2023 at 00:52:20 UTC, Ali Çehreli wrote: Although that difference is a bug, iota does have a special floating point implementation to prevent the accumulation of floating point errors. Thank you for this clarification Ali. I appreciate the fact that there is a specialized implementation for float types in an attempt to mitigate error accumulation. After posting my previous message I became convinced that the behavior I was seeing was indeed a bug. The specialized fp implementation simply does not conform to the semantics specified in the documentation: "If begin < end && step < 0 or begin > end && step > 0 or begin == end, then an empty range is returned." The culprit is this assert in the `in` block of the fp implementation: ``` assert((end - begin) / step >= 0, "iota: incorrect startup parameters"); ``` This effectively prevents iota from ever returning an empty range. Git blame points to a commit from March 2015. It's unbelievable to me this hasn't been fixed in almost 8 years. Would anyone volunteer to file a bug report? I attempted to do it myself but I would need to create an account in the Issue Tracking System, and apparently it doesn't accept gmail addresses anymore? (facepalm). Arredondo.
Re: Bug or feature? iota has different semantics for integer and float arguments
On 1/6/23 15:23, Arredondo wrote: > then you get an exception (incorrect startup parameters). Although that difference is a bug, iota does have a special floating point implementation to prevent the accumulation of floating point errors. I mention it as item 4 here: https://www.youtube.com/watch?v=gwUcngTmKhg=634s Briefly, iota's regular popFront() is a trivial front += step but it is ++n for floating types so that front can be begin + (n * step) for them. The iota discussion starts at an earlier point in the video here: https://www.youtube.com/watch?v=gwUcngTmKhg=558s Ali
Bug or feature? iota has different semantics for integer and float arguments
Consider: ``` import std.range.iota; auto r = iota(5, 0); ``` `r` is an empty range, as it should be. But if you call: ``` auto r = iota(5.0, 0); ``` then you get an exception (incorrect startup parameters). This was unexpected, and a pain to debug. What is the rationale behind iota having different semantics depending on whether the arguments are floats or not? Arredondo.
Proper way to override (swap) runtime and phobos. [feature request?]
for development purposes. is there are correct way to somehow (partially or complete) override druntime and phobos? or, maybe, some code injection/patching mechanisms during compilation of own code.
Re: save() feature for iota
On Friday, 4 November 2022 at 08:48:36 UTC, Salih Dincer wrote: On Thursday, 3 November 2022 at 11:58:20 UTC, Paul Backus wrote: On Thursday, 3 November 2022 at 06:26:22 UTC, Salih Dincer Looking at the source, it seems that only the numeric overloads of `iota` implement `save`. I think this is probably just an oversight, though, since I can't see any reason why `save` wouldn't work just as well for the generic version. The problem I'm having here seems to be chunk related. But using a template like iota!char for some reason does not affect the output result. I showed these situations in the example in the Turkish forum: https://forum.dlang.org/thread/jbklbbozmisahohou...@forum.dlang.org SDB@79 See Pauls response
Re: save() feature for iota
On Thursday, 3 November 2022 at 11:58:20 UTC, Paul Backus wrote: On Thursday, 3 November 2022 at 06:26:22 UTC, Salih Dincer Looking at the source, it seems that only the numeric overloads of `iota` implement `save`. I think this is probably just an oversight, though, since I can't see any reason why `save` wouldn't work just as well for the generic version. The problem I'm having here seems to be chunk related. But using a template like iota!char for some reason does not affect the output result. I showed these situations in the example in the Turkish forum: https://forum.dlang.org/thread/jbklbbozmisahohou...@forum.dlang.org SDB@79
Re: save() feature for iota
On 11/3/22 04:58, Paul Backus wrote: > https://issues.dlang.org/show_bug.cgi?id=23453 Even though iterating over UTF value ranges don't make sense in general, they would work for some values including the ASCII range. Ali
Re: save() feature for iota
On Thursday, 3 November 2022 at 06:26:22 UTC, Salih Dincer wrote: Hi All, Isn't there a save feature for `iota()`? Looking at the source, it seems that only the numeric overloads of `iota` implement `save`. I think this is probably just an oversight, though, since I can't see any reason why `save` wouldn't work just as well for the generic version. I've submitted an enhancement request for this to the D bug tracker: https://issues.dlang.org/show_bug.cgi?id=23453
save() feature for iota
Hi All,
Isn't there a save feature for `iota()`?
```d
import std.stdio;
import std.range;
void main()
{
foreach(num; iota!char('a', 'f').chunks(3)/*
"onetwosixfour".chunks(3)//*/
) {
//auto n = num.save();
num.writeln(": ", num.walkLength);
}
} /* Prints:
: 3
: 2
*/
```
So is there a way to find out the length of an `iota()` range
without consuming it?
SDB@79
Re: Create alias of same name in inner scope, bug or feature?
On Saturday, 14 August 2021 at 08:23:20 UTC, user1234 wrote: On Saturday, 14 August 2021 at 04:09:34 UTC, Tejas wrote: [...] Oh right, the ```.``` operator will reference variable in the _module_ scope, not just the _immediate outer scope_, you can use the module name to disambiguate as well. To extend Mike answer, the general rule is that if you can distinguish two names there's no shadowing. Understood
Re: Create alias of same name in inner scope, bug or feature?
On Saturday, 14 August 2021 at 04:09:34 UTC, Tejas wrote: [...] Oh right, the ```.``` operator will reference variable in the _module_ scope, not just the _immediate outer scope_, you can use the module name to disambiguate as well. To extend Mike answer, the general rule is that if you can distinguish two names there's no shadowing.
Re: Create alias of same name in inner scope, bug or feature?
On Saturday, 14 August 2021 at 04:01:31 UTC, Mike Parker wrote:
On Saturday, 14 August 2021 at 03:47:05 UTC, Tejas wrote:
```d
import std;
auto abc(T)(auto ref T a, auto ref T b){
return a+b;
}
auto def(T)(auto ref T a, auto ref T b){
return a*b;
}
alias macro_1 = abc;
void main()
{
writeln(macro_1(15, 20));
alias macro_1 = def;// is this NOT considered variable
shadowing?
writeln(macro_1(100, 20));
}
```
Shadowing local symbols is illegal. But it's okay for local
symbols to have the same name as module-scope symbols. You can
disambigbuate with [the module scope operator][1]:
```d
void main()
macro_1(); // the local symbol
.macro_1(); // the external symbol
}
```
[1]: https://dlang.org/spec/module.html#module_scope_operators
Oh right, the ```.``` operator will reference variable in the
_module_ scope, not just the _immediate outer scope_, that's why
it is not considered shadowing in that case.
Thank you very much!
Re: Create alias of same name in inner scope, bug or feature?
On Saturday, 14 August 2021 at 03:47:05 UTC, Tejas wrote:
```d
import std;
auto abc(T)(auto ref T a, auto ref T b){
return a+b;
}
auto def(T)(auto ref T a, auto ref T b){
return a*b;
}
alias macro_1 = abc;
void main()
{
writeln(macro_1(15, 20));
alias macro_1 = def;// is this NOT considered variable
shadowing?
writeln(macro_1(100, 20));
}
```
Shadowing local symbols is illegal. But it's okay for local
symbols to have the same name as module-scope symbols. You can
disambigbuate with [the module scope operator][1]:
```d
void main()
macro_1(); // the local symbol
.macro_1(); // the external symbol
}
```
[1]: https://dlang.org/spec/module.html#module_scope_operators
Create alias of same name in inner scope, bug or feature?
```d
import std;
auto abc(T)(auto ref T a, auto ref T b){
return a+b;
}
auto def(T)(auto ref T a, auto ref T b){
return a*b;
}
alias macro_1 = abc;
void main()
{
writeln(macro_1(15, 20));
alias macro_1 = def;// is this NOT considered variable
shadowing?
writeln(macro_1(100, 20));
}
```
Re: Is returning void functions inside void functions a feature or an artifact?
On Tuesday, 3 August 2021 at 10:28:53 UTC, Rekel wrote:
On Tuesday, 3 August 2021 at 00:53:43 UTC, user1234 wrote:
You got the answer in another reply but here is a bit of more
fun:
```d
void main() {
return cast(void) 1;
}
```
What does casting to void do? Does it just ignore whatever
follows it?
Yes.
Re: Is returning void functions inside void functions a feature or an artifact?
On Tuesday, 3 August 2021 at 00:53:43 UTC, user1234 wrote:
You got the answer in another reply but here is a bit of more
fun:
```d
void main() {
return cast(void) 1;
}
```
What does casting to void do? Does it just ignore whatever
follows it?
On Tuesday, 3 August 2021 at 07:23:34 UTC, Patrick Schluter wrote:
Wow. Just discovered that C accepts it. After 35 years of daily
use of C, there are still things to discover.
Hehe, glad to hear I'm not the only one. Feel like making a
request to add this to the learning pages now "x3
Re: Is returning void functions inside void functions a feature or an artifact?
On Monday, 2 August 2021 at 14:46:36 UTC, jfondren wrote: On Monday, 2 August 2021 at 14:31:45 UTC, Rekel wrote: [...] I don't know where you can find this in the docs, but what doesn't seem trivial about it? The type of the expression `print()` is void. That's the type that `doSomething` returns. That's the type of the expression that `doSomething` does return and the type of the expression following a `return` keyword in `doSomething`. Rather than a rule expressly permitting this, I would expect to find to either nothing (it's permitted because it makes sense) or a rule against it (it's expressly forbidden because it has to be to not work, because it makes sense). C, C++, Rust, and Zig are all fine with this. Nim doesn't like it. Wow. Just discovered that C accepts it. After 35 years of daily use of C, there are still things to discover.
Re: Is returning void functions inside void functions a feature or an artifact?
On Monday, 2 August 2021 at 14:31:45 UTC, Rekel wrote:
I recently found one can return function calls to void
functions, though I don't remember any documentation mentioning
this even though it doesn't seem trivial.
[...]
If this is intended, where could I find this in the docs? I
haven't been able to find previous mentions on this, neither on
the forum.
You got the answer in another reply but here is a bit of more fun:
```d
void main() {
return cast(void) 1;
}
```
it's all about the type system and conversions
Re: Is returning void functions inside void functions a feature or an artifact?
On Mon, Aug 02, 2021 at 04:42:14PM +, Rekel via Digitalmars-d-learn wrote:
[...]
> Also slightly off topic, but when would one use an alias instead of a
> function/delegate? I haven't used aliases before.
When you want a compile-time binding that could potentially elide the
indirect function call to a delegate.
// This generates a specialized template instance with
// `callback` bound to the passed-in compile-time argument, for
// each call to `myFunc`.
auto myFunc(alias callback)(...) { ... }
// This is a single common function that receives an opaque
// runtime delegate and binds it at runtime.
auto myFunc(int delegate(...) callback, ...) { ... }
T
--
An elephant: A mouse built to government specifications. -- Robert Heinlein
Re: Is returning void functions inside void functions a feature or an artifact?
On 8/2/21 9:42 AM, Rekel wrote: > when would one use an alias instead of a > function/delegate? I haven't used aliases before. alias will match both functions and delegates... and... any symbol at all. So, if you don't have a reason to constain the user, callable template parameters are most usefully aliases. Ali
Re: Is returning void functions inside void functions a feature or an artifact?
On Monday, 2 August 2021 at 14:51:07 UTC, H. S. Teoh wrote: This is intentional, in order to make it easier to write generic code without always having to special-case functions that don't return anything. Ooh that indeed seems useful. Thanks for the hint. Also slightly off topic, but when would one use an alias instead of a function/delegate? I haven't used aliases before.
Re: Is returning void functions inside void functions a feature or an artifact?
On Monday, 2 August 2021 at 14:46:36 UTC, jfondren wrote: C, C++, Rust, and Zig are all fine with this. Nim doesn't like it. I had no clue, never seen it used in any case. I've always assumed one couldn't return void as it's not a value. I guess intuitions aren't always universal . Good to know c is fine with this too! ^^
Re: Is returning void functions inside void functions a feature or an artifact?
On Mon, Aug 02, 2021 at 02:31:45PM +, Rekel via Digitalmars-d-learn wrote:
> I recently found one can return function calls to void functions,
> though I don't remember any documentation mentioning this even though
> it doesn't seem trivial.
This is intentional, in order to make it easier to write generic code
without always having to special-case functions that don't return
anything. E.g.:
auto myWrapper(alias func, Args...)(Args args) {
// Don't have to special case void return.
return func(args);
}
int hooray(int i) { return i+1; }
void boo(int j) { return; }
int z = myWrapper!hooray(1);
myWrapper!boo(2);
Otherwise you'd have to litter your code with redundant special cases:
auto myWrapper(alias func, Args...)(Args args) {
static if (is(ReturnType!func == void))
func(args);
else
return func(args); // same thing but different
}
Allowing `return func(args)` for void functions eliminates the need for
such special cases.
T
--
"640K ought to be enough" -- Bill G. (allegedly), 1984. "The Internet is not a
primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on
Microsoft's strategy" -- Bill G., 1999.
Re: Is returning void functions inside void functions a feature or an artifact?
On Monday, 2 August 2021 at 14:31:45 UTC, Rekel wrote:
I recently found one can return function calls to void
functions, though I don't remember any documentation mentioning
this even though it doesn't seem trivial.
```d
void print(){
writeln("0");
}
void doSomething(int a){
if (a==0)
return print();
writeln("1");
}
void main(string[] args) {
doSomething(0); // Prints 0 but not 1.
}
```
If this is intended, where could I find this in the docs? I
haven't been able to find previous mentions on this, neither on
the forum.
I don't know where you can find this in the docs, but what
doesn't seem trivial about it? The type of the expression
`print()` is void. That's the type that `doSomething` returns.
That's the type of the expression that `doSomething` does return
and the type of the expression following a `return` keyword in
`doSomething`. Rather than a rule expressly permitting this, I
would expect to find to either nothing (it's permitted because it
makes sense) or a rule against it (it's expressly forbidden
because it has to be to not work, because it makes sense).
C, C++, Rust, and Zig are all fine with this. Nim doesn't like it.
Is returning void functions inside void functions a feature or an artifact?
I recently found one can return function calls to void functions,
though I don't remember any documentation mentioning this even
though it doesn't seem trivial.
```d
void print(){
writeln("0");
}
void doSomething(int a){
if (a==0)
return print();
writeln("1");
}
void main(string[] args) {
doSomething(0); // Prints 0 but not 1.
}
```
If this is intended, where could I find this in the docs? I
haven't been able to find previous mentions on this, neither on
the forum.
Re: Bug or Feature: unsigned integer overflow
On Saturday, 14 December 2019 at 10:32:10 UTC, berni44 wrote: On Saturday, 14 December 2019 at 09:33:13 UTC, Tobias Pankrath wrote: See: https://dlang.org/spec/lex.html#integerliteral What I am aiming at: Is the spec wrong or am I misunderstanding it and did this change recently? You are right. The implementation does not do what the specs tell here. I filed a bug report: https://issues.dlang.org/show_bug.cgi?id=20449 Thank you!
Re: Bug or Feature: unsigned integer overflow
On Saturday, 14 December 2019 at 09:33:13 UTC, Tobias Pankrath wrote: See: https://dlang.org/spec/lex.html#integerliteral What I am aiming at: Is the spec wrong or am I misunderstanding it and did this change recently? You are right. The implementation does not do what the specs tell here. I filed a bug report: https://issues.dlang.org/show_bug.cgi?id=20449
Re: Bug or Feature: unsigned integer overflow
On Saturday, 14 December 2019 at 07:44:37 UTC, berni44 wrote:
On Saturday, 14 December 2019 at 07:09:30 UTC, Tobias Pankrath
wrote:
void main()
{
auto x = 9223372036854775808; // long.max + 1
}
You need to tell, that this is an unsigned long literal, else
the compiler treats it as an int:
void main()
{
auto x = 9223372036854775808UL; // long.max + 1
}
As far as I understand the spec, the type is inferred from the
value range:
Literal Type
Usual decimal notation
0 .. 2_147_483_647 int
2_147_483_648 .. 9_223_372_036_854_775_807 long
9_223_372_036_854_775_808 .. 18_446_744_073_709_551_615 ulong
See: https://dlang.org/spec/lex.html#integerliteral
What I am aiming at: Is the spec wrong or am I misunderstanding
it and did this change recently?
Re: Bug or Feature: unsigned integer overflow
On Saturday, 14 December 2019 at 07:09:30 UTC, Tobias Pankrath
wrote:
void main()
{
auto x = 9223372036854775808; // long.max + 1
}
You need to tell, that this is an unsigned long literal, else the
compiler treats it as an int:
void main()
{
auto x = 9223372036854775808UL; // long.max + 1
}
Bug or Feature: unsigned integer overflow
void main()
{
auto x = 9223372036854775808; // long.max + 1
}
onlineapp.d(3): Error: signed integer overflow
According to spec x should be of type ulong and this should
compile? It indeed compiles if I add the uL postfix.
Is this a bug or indented behaviour?
Re: Bug or Feature: `this` necessary to call function with template this parameter
On Wednesday, 30 October 2019 at 20:22:25 UTC, Q. Schroll wrote:
struct Example
{
private void helper(int i, this X)() { }
void funcTempl(T, this X)(T value)
{
this.helper!0();
// ^ Why do I need this?
}
}
void main()
{
auto ex = Example();
ex.funcTempl(1);
}
The question is in the comment in the code. Is that intentional
or a bug?
It's a bug - filed as
https://issues.dlang.org/show_bug.cgi?id=20341.
However, note that typeof(this) inside funcTempl() is different
from X, so that inside helper(), X will not be the same as in
funcTempl(). To fix this, you will need to pass X on to helper as
helper!(0, X). When you do this, you no longer need 'this.' in
front of the instantiation.
--
Simen
Bug or Feature: `this` necessary to call function with template this parameter
struct Example
{
private void helper(int i, this X)() { }
void funcTempl(T, this X)(T value)
{
this.helper!0();
// ^ Why do I need this?
}
}
void main()
{
auto ex = Example();
ex.funcTempl(1);
}
The question is in the comment in the code. Is that intentional
or a bug?
Re: Cannot take the .keys of shared AA. Is this a regression in 2.087 or a feature?
On Friday, August 16, 2019 2:16:31 AM MDT Piotr Mitana via Digitalmars-d-
learn wrote:
> On Thursday, 15 August 2019 at 19:51:30 UTC, Jonathan M Davis
>
> wrote:
> > Not being able to implicitly convert to const is a bit odd, but
> > arguably, nothing should ever be called on a shared AA anyway.
> > If an operation isn't thread-safe, then it shouldn't work with
> > shared. To use a shared object safely, you have to protect
> > access to it with a mutex or some other synchronization
> > mechanism, after which you would normally cast away shared to
> > operate on the object as thread-local while the lock is in
> > place and then release the lock when you're done (also making
> > sure that no thread-local references exist when the lock is
> > released). Because keys is not at all thread-safe, I'd strongly
> > argue that it should not work on a shared AA, and if it does,
> > that's a bug.
>
> OK, I get the point. So I should go with something similar to
> this, right?
>
> import core.sync.mutex;
> import std;
>
> shared(string[string]) dict;
> shared(Mutex) mtx;
>
> shared static this()
> {
> mtx = new shared Mutex;
> }
>
> void main()
> {
> mtx.lock;
> (cast(string[string]) dict).keys;
> mtx.unlock;
> }
>
> Or I could use synchronized, if dict was inside a class. Thank
> you!
Yes. Or you can use synchronized blocks. e.g.
synchronized(mtx)
{
(cast(string[string]) dict).keys;
}
- Jonathan M Davis
Re: Cannot take the .keys of shared AA. Is this a regression in 2.087 or a feature?
On Thursday, 15 August 2019 at 19:51:30 UTC, Jonathan M Davis
wrote:
Not being able to implicitly convert to const is a bit odd, but
arguably, nothing should ever be called on a shared AA anyway.
If an operation isn't thread-safe, then it shouldn't work with
shared. To use a shared object safely, you have to protect
access to it with a mutex or some other synchronization
mechanism, after which you would normally cast away shared to
operate on the object as thread-local while the lock is in
place and then release the lock when you're done (also making
sure that no thread-local references exist when the lock is
released). Because keys is not at all thread-safe, I'd strongly
argue that it should not work on a shared AA, and if it does,
that's a bug.
OK, I get the point. So I should go with something similar to
this, right?
import core.sync.mutex;
import std;
shared(string[string]) dict;
shared(Mutex) mtx;
shared static this()
{
mtx = new shared Mutex;
}
void main()
{
mtx.lock;
(cast(string[string]) dict).keys;
mtx.unlock;
}
Or I could use synchronized, if dict was inside a class. Thank
you!
Re: Cannot take the .keys of shared AA. Is this a regression in 2.087 or a feature?
On Thursday, 15 August 2019 at 19:51:30 UTC, Jonathan M Davis
wrote:
n Thursday, August 15, 2019 11:33:06 AM MDT Piotr Mitana via
Digitalmars-d- learn wrote:
Code:
import std;
shared(string[string]) dict;
void main()
{
dict.keys;
}
Error:
/dlang/dmd/linux/bin64/../../src/druntime/import/object.d(3417):
Error: cannot implicitly convert expression aa of type
shared(string[string]) to const(shared(string)[string])
onlineapp.d(7): Error: template instance
`object.keys!(shared(string[string]), shared(string), string)`
error instantiating
Before D 2.087 it compiled - is this a regression?
Not being able to implicitly convert to const is a bit odd, but
arguably, nothing should ever be called on a shared AA anyway.
If an operation isn't thread-safe, then it shouldn't work with
shared. To use a shared object safely, you have to protect
access to it with a mutex or some other synchronization
mechanism, after which you would normally cast away shared to
operate on the object as thread-local while the lock is in
place and then release the lock when you're done (also making
sure that no thread-local references exist when the lock is
released). Because keys is not at all thread-safe, I'd strongly
argue that it should not work on a shared AA, and if it does,
that's a bug.
- Jonathan M Davis
D really needs some official thread-safe implementations of
containers, hashmaps etc.
Re: Cannot take the .keys of shared AA. Is this a regression in 2.087 or a feature?
n Thursday, August 15, 2019 11:33:06 AM MDT Piotr Mitana via Digitalmars-d-
learn wrote:
> Code:
>
> import std;
>
> shared(string[string]) dict;
>
> void main()
> {
> dict.keys;
> }
>
> Error:
>
> /dlang/dmd/linux/bin64/../../src/druntime/import/object.d(3417):
> Error: cannot implicitly convert expression aa of type
> shared(string[string]) to const(shared(string)[string])
> onlineapp.d(7): Error: template instance
> `object.keys!(shared(string[string]), shared(string), string)`
> error instantiating
>
> Before D 2.087 it compiled - is this a regression?
Not being able to implicitly convert to const is a bit odd, but arguably,
nothing should ever be called on a shared AA anyway. If an operation isn't
thread-safe, then it shouldn't work with shared. To use a shared object
safely, you have to protect access to it with a mutex or some other
synchronization mechanism, after which you would normally cast away shared
to operate on the object as thread-local while the lock is in place and then
release the lock when you're done (also making sure that no thread-local
references exist when the lock is released). Because keys is not at all
thread-safe, I'd strongly argue that it should not work on a shared AA, and
if it does, that's a bug.
- Jonathan M Davis
Cannot take the .keys of shared AA. Is this a regression in 2.087 or a feature?
Code:
import std;
shared(string[string]) dict;
void main()
{
dict.keys;
}
Error:
/dlang/dmd/linux/bin64/../../src/druntime/import/object.d(3417):
Error: cannot implicitly convert expression aa of type
shared(string[string]) to const(shared(string)[string])
onlineapp.d(7): Error: template instance
`object.keys!(shared(string[string]), shared(string), string)`
error instantiating
Before D 2.087 it compiled - is this a regression?
Re: Any full feature xml library available?
On Fri, 2019-05-03 at 14:07 -0700, H. S. Teoh via Digitalmars-d-learn wrote: > […] > The problem is that while there is no shortage of complaints about XML > support in D, there is a great dearth of people actually willing to *do* > something about it. In my case it is because I have no need to deal with XML using D, and I am not in the market for paid work. Those actually doing stuff with XML and D have far fewer excuses. > At least Jonathan wrote dxml, which arguably would meet the need in most > cases. So there's that. But if somebody wants entity references and > other similar things, the only recourse would appear to be to wrap > libxml2. Given D's aptitude at interfacing with C, this should be much > simpler than writing dxml. It just needs someone to sit down and *do* > it. That people who have the problem can write many lengthy emails on the D lists rather than doing something about creating a D binding to libxml2 is clearly the bulk of the problem. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Any full feature xml library available?
On Friday, 3 May 2019 at 21:07:29 UTC, H. S. Teoh wrote: On Fri, May 03, 2019 at 09:56:56PM +0100, Russel Winder via Digitalmars-d-learn wrote: On Thu, 2019-05-02 at 09:28 -0700, H. S. Teoh via Digitalmars-d-learn wrote: > On Thu, May 02, 2019 at 05:23:29PM +0100, Russel Winder via > Digitalmars-d-learn wrote: > [...] > > [...] > [...] > > No particular reason, except nobody has taken up the task > yet. Would you? If I were interested in XML processing yes I would. However, just at the moment I am doing things with MPEG-TS and gstreamer-rs. I may investigate the analogue for GstreamerD. On the other hand there are enough people moaning about std.xml and the general lack of quality, high performance D support for XML that there is clearly a lot of people who should be interested in creating a D binding to libxml2. [...] The problem is that while there is no shortage of complaints about XML support in D, there is a great dearth of people actually willing to *do* something about it. At least Jonathan wrote dxml, which arguably would meet the need in most cases. So there's that. But if somebody wants entity references and other similar things, the only recourse would appear to be to wrap libxml2. Given D's aptitude at interfacing with C, this should be much simpler than writing dxml. It just needs someone to sit down and *do* it. T I am trying to port libxml++ to D. I use dstep to generate the binding to libxml2, and then porting c++ to D. But I don't have much time, and there are some failures with dstep. I don't have a computer at home, so I must use termux to coding. I hope someone can continue to maintaining the android port of ldc.
Re: Any full feature xml library available?
On Fri, May 03, 2019 at 09:56:56PM +0100, Russel Winder via Digitalmars-d-learn wrote: > On Thu, 2019-05-02 at 09:28 -0700, H. S. Teoh via Digitalmars-d-learn > wrote: > > On Thu, May 02, 2019 at 05:23:29PM +0100, Russel Winder via > > Digitalmars-d-learn wrote: > > [...] > > > There are situations where you create a binding in preference to > > > writing something from scratch. cf. gtk, gstreamer, etc. so why > > > not libxml2? > > [...] > > > > No particular reason, except nobody has taken up the task yet. Would > > you? > > If I were interested in XML processing yes I would. However, just at > the moment I am doing things with MPEG-TS and gstreamer-rs. I may > investigate the analogue for GstreamerD. > > On the other hand there are enough people moaning about std.xml and > the general lack of quality, high performance D support for XML that > there is clearly a lot of people who should be interested in creating > a D binding to libxml2. [...] The problem is that while there is no shortage of complaints about XML support in D, there is a great dearth of people actually willing to *do* something about it. At least Jonathan wrote dxml, which arguably would meet the need in most cases. So there's that. But if somebody wants entity references and other similar things, the only recourse would appear to be to wrap libxml2. Given D's aptitude at interfacing with C, this should be much simpler than writing dxml. It just needs someone to sit down and *do* it. T -- Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.
Re: Any full feature xml library available?
On Thu, 2019-05-02 at 09:28 -0700, H. S. Teoh via Digitalmars-d-learn wrote: > On Thu, May 02, 2019 at 05:23:29PM +0100, Russel Winder via > Digitalmars-d-learn wrote: > [...] > > There are situations where you create a binding in preference to > > writing something from scratch. cf. gtk, gstreamer, etc. so why not > > libxml2? > [...] > > No particular reason, except nobody has taken up the task yet. Would > you? If I were interested in XML processing yes I would. However, just at the moment I am doing things with MPEG-TS and gstreamer-rs. I may investigate the analogue for GstreamerD. On the other hand there are enough people moaning about std.xml and the general lack of quality, high performance D support for XML that there is clearly a lot of people who should be interested in creating a D binding to libxml2. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Any full feature xml library available?
On 03/05/2019 4:23 AM, Russel Winder wrote: On Fri, 2019-05-03 at 03:50 +1200, rikki cattermole via Digitalmars-d- learn wrote: On 03/05/2019 3:36 AM, Russel Winder wrote: […] libxml2 is definitely usable from Python, it must be usable from D. Of course, I am assuming libxml2 has the facilities required. libxml2 is precisely what I meant. We just don't have the libraries written in D at this point. There are situations where you create a binding in preference to writing something from scratch. cf. gtk, gstreamer, etc. so why not libxml2? I am suggesting a binding. I think we have our wires crossed on this.
Re: Any full feature xml library available?
On Thursday, 2 May 2019 at 15:50:53 UTC, rikki cattermole wrote: On 03/05/2019 3:36 AM, Russel Winder wrote: On Thu, 2019-05-02 at 02:11 +1200, rikki cattermole via Digitalmars-d- learn wrote: […] It does not. Those features come under the big bad guys feature list. Gonna have to go to C for it. Surely that means you can use Python, Rust, C++, or D rather than having to descend to using C? libxml2 is definitely usable from Python, it must be usable from D. Of course, I am assuming libxml2 has the facilities required. libxml2 is precisely what I meant. We just don't have the libraries written in D at this point. Apparently, bindings to libxml2 existed back in 2008. http://www.dsource.org/projects/bcd/ Bastiaan
Re: Any full feature xml library available?
On Thu, May 02, 2019 at 05:23:29PM +0100, Russel Winder via Digitalmars-d-learn wrote: [...] > There are situations where you create a binding in preference to > writing something from scratch. cf. gtk, gstreamer, etc. so why not > libxml2? [...] No particular reason, except nobody has taken up the task yet. Would you? T -- Once bitten, twice cry...
Re: Any full feature xml library available?
On Fri, 2019-05-03 at 03:50 +1200, rikki cattermole via Digitalmars-d- learn wrote: > On 03/05/2019 3:36 AM, Russel Winder wrote: > > […] > > libxml2 is definitely usable from Python, it must be usable from D. > > Of > > course, I am assuming libxml2 has the facilities required. > > libxml2 is precisely what I meant. > > We just don't have the libraries written in D at this point. There are situations where you create a binding in preference to writing something from scratch. cf. gtk, gstreamer, etc. so why not libxml2? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Any full feature xml library available?
On 03/05/2019 3:36 AM, Russel Winder wrote: On Thu, 2019-05-02 at 02:11 +1200, rikki cattermole via Digitalmars-d- learn wrote: […] It does not. Those features come under the big bad guys feature list. Gonna have to go to C for it. Surely that means you can use Python, Rust, C++, or D rather than having to descend to using C? libxml2 is definitely usable from Python, it must be usable from D. Of course, I am assuming libxml2 has the facilities required. libxml2 is precisely what I meant. We just don't have the libraries written in D at this point.
Re: Any full feature xml library available?
On Thu, 2019-05-02 at 02:11 +1200, rikki cattermole via Digitalmars-d- learn wrote: […] > > It does not. Those features come under the big bad guys feature list. > > Gonna have to go to C for it. Surely that means you can use Python, Rust, C++, or D rather than having to descend to using C? libxml2 is definitely usable from Python, it must be usable from D. Of course, I am assuming libxml2 has the facilities required. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Any full feature xml library available?
On 02/05/2019 2:04 AM, Domain wrote: On Wednesday, 1 May 2019 at 13:57:04 UTC, bachmeier wrote: On Wednesday, 1 May 2019 at 13:54:08 UTC, Domain wrote: I need a xml library which support document entity or xinclude. The xml may like this: ]> http://www.w3.org/2001/XInclude;> Have you looked at this? https://github.com/jmdavis/dxml Yes, but I don't think dxml support these features. It does not. Those features come under the big bad guys feature list. Gonna have to go to C for it.
Re: Any full feature xml library available?
On Wednesday, 1 May 2019 at 13:57:04 UTC, bachmeier wrote: On Wednesday, 1 May 2019 at 13:54:08 UTC, Domain wrote: I need a xml library which support document entity or xinclude. The xml may like this: ]> http://www.w3.org/2001/XInclude;> Have you looked at this? https://github.com/jmdavis/dxml Yes, but I don't think dxml support these features.
Re: Any full feature xml library available?
On Wednesday, 1 May 2019 at 13:54:08 UTC, Domain wrote: I need a xml library which support document entity or xinclude. The xml may like this: ]> http://www.w3.org/2001/XInclude;> Have you looked at this? https://github.com/jmdavis/dxml
Any full feature xml library available?
I need a xml library which support document entity or xinclude. The xml may like this: ]> http://www.w3.org/2001/XInclude;>
Re: Can you get typeof(this) in a mixin template - trying to mimic a Kotlin feature here.
On Tuesday, 28 August 2018 at 20:58:23 UTC, Alex wrote:
Isn't the problem, that inside a template a declaration is
expected, and not a foreach?
Boh, you're right. I guess I misunderstood mixin templates. Found
a way with a normap function though :p
void mapSelf(alias self, alias aa)() { ... }
this(map) {
mapSelf!(this, map);
}
https://run.dlang.io/is/EhDpOM
Re: Can you get typeof(this) in a mixin template - trying to mimic a Kotlin feature here.
On Tuesday, 28 August 2018 at 20:39:16 UTC, aliak wrote:
Hi,
I'm trying to do something similar to what Kotlin allows with
assigning to member variables from a map. The syntax is very
readable and looks like:
class User(val map: Map) {
val name: String by map
val age: Int by map
}
So I'm trying to do something similar in D:
mixin template MapMembers(alias aa) {
foreach (name; typeof(this).tupleof) {
// if name is in aa, then mixin(m = aa[" ~ m ~ "]) ... ish
}
}
struct User {
this(Variant[string] aa) {
mixin MapMembers!aa;
}
}
Seems I can't do typeof(this) inside the mixin.
One workaround is to explicitly pass the type "User" to the
template mixin, but it feels like this is something that should
work and I'm just unfamiliar with template mixins and their
usage.
Cheers,
- Ali
[0]
https://kotlinlang.org/docs/reference/delegated-properties.html#storing-properties-in-a-map
Isn't the problem, that inside a template a declaration is
expected, and not a foreach?
This works as expected:
´´´
import std.experimental.all;
void main()
{
writeln("Edit source/app.d to start your project.");
}
mixin template MapMembers(alias aa) {
typeof(this) var;
/*
foreach (name; typeof(this).tupleof) {
// if name is in aa, then mixin(m = aa[" ~ m ~ "]) ... ish
}
*/
}
struct User {
this(Variant[string] aa) {
mixin MapMembers!aa;
}
}
//mixin MapMembers!(Variant[string].init);
´´´
Can you get typeof(this) in a mixin template - trying to mimic a Kotlin feature here.
Hi,
I'm trying to do something similar to what Kotlin allows with
assigning to member variables from a map. The syntax is very
readable and looks like:
class User(val map: Map) {
val name: String by map
val age: Int by map
}
So I'm trying to do something similar in D:
mixin template MapMembers(alias aa) {
foreach (name; typeof(this).tupleof) {
// if name is in aa, then mixin(m = aa[" ~ m ~ "]) ... ish
}
}
struct User {
this(Variant[string] aa) {
mixin MapMembers!aa;
}
}
Seems I can't do typeof(this) inside the mixin.
One workaround is to explicitly pass the type "User" to the
template mixin, but it feels like this is something that should
work and I'm just unfamiliar with template mixins and their usage.
Cheers,
- Ali
[0]
https://kotlinlang.org/docs/reference/delegated-properties.html#storing-properties-in-a-map
Re: Package method is not virtual and cannot override - a bug or a feature?
On Thursday, May 10, 2018 11:52:38 Piotr Mitana via Digitalmars-d-learn
wrote:
> Given this code:
>
> abstract class A
> {
> package @property void x(int x);
> package @property int x();
> }
>
> class B : A
> {
> package @property override void x(int x) {}
> package @property override int x() { return 0; }
> }
>
> void main() {}
>
> I get the following message:
>
> onlineapp.d(9): Error: function `onlineapp.B.x` package method is
> not virtual and cannot override
> onlineapp.d(10): Error: function `onlineapp.B.x` package method
> is not virtual and cannot override
>
> Why is that? If the access specifier is private, I can perfectly
> understand it - subclasses can't call the private method of
> parent class, so there's no need in making it virtual. For
> protected/public the code compiles. However, for the package
> protection it may happen that a subclass is in the same package
> (and just happened to me).
>
> Should I file a bug or is there a reason for such behavior?
I don't rememeber the reasoning at the moment, but it's most definitely not
a bug and is on purpose. There's probably a "won't fix" bug in bugzilla for
it if you go digging.
- Jonathan M Davis
Package method is not virtual and cannot override - a bug or a feature?
Given this code:
abstract class A
{
package @property void x(int x);
package @property int x();
}
class B : A
{
package @property override void x(int x) {}
package @property override int x() { return 0; }
}
void main() {}
I get the following message:
onlineapp.d(9): Error: function `onlineapp.B.x` package method is
not virtual and cannot override
onlineapp.d(10): Error: function `onlineapp.B.x` package method
is not virtual and cannot override
Why is that? If the access specifier is private, I can perfectly
understand it - subclasses can't call the private method of
parent class, so there's no need in making it virtual. For
protected/public the code compiles. However, for the package
protection it may happen that a subclass is in the same package
(and just happened to me).
Should I file a bug or is there a reason for such behavior?
Re: Can't add ubytes together to make a ubyte... bug or feature?
On 03/17/2018 11:36 AM, Jonathan wrote: `(a+b)&0xff` What is this syntax?! Could you give a link to this in the D documentation? Here is my description of bitwise AND: http://ddili.org/ders/d.en/bit_operations.html#ix_bit_operations.&,%20bitwise%20and The section titled "Masking" on the same page explains what &0xff part means. I am not even sure how to look it up... I hope my index section is useful in such cases. Just search for the & character there: http://ddili.org/ders/d.en/ix.html Yes, there are many meanings of the & character but I think it's still useful. :) Ali
Re: Can't add ubytes together to make a ubyte... bug or feature?
On Saturday, 17 March 2018 at 18:56:55 UTC, Dominikus Dittes Scherkl wrote: On Saturday, 17 March 2018 at 18:36:35 UTC, Jonathan wrote: On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe wrote: On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend wrote: I don't care if my computer needs to do math on a 4 byte basis, I'm not writing assembly. x86 actually doesn't need to do math that way, if you were writing assembly, it would just work. This is just an annoying rule brought over by C. Can I prevent the initial implicit casts? Nope, though you can help tell the compiler that you want it to fit there by doing stuff like ubyte a = 200; ubyte b = 100; ubyte c = (a+b)&0xff; or something like that, so the expression is specifically proven to fit in the byte with compile time facts. `(a+b)&0xff` What is this syntax?! Could you give a link to this in the D documentation? I am not even sure how to look it up... & is the normal binary and operation, same in C, C++, Java, ... 0xFF is a hexadecimal constant (255), which the compiler knows fit in an ubyte So what do you not understand about this syntax? I guess he doesn't understand bitwise operations. Also don't you mean bitwise and?
Re: Can't add ubytes together to make a ubyte... bug or feature?
On Saturday, 17 March 2018 at 18:36:35 UTC, Jonathan wrote: On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe wrote: On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend wrote: I don't care if my computer needs to do math on a 4 byte basis, I'm not writing assembly. x86 actually doesn't need to do math that way, if you were writing assembly, it would just work. This is just an annoying rule brought over by C. Can I prevent the initial implicit casts? Nope, though you can help tell the compiler that you want it to fit there by doing stuff like ubyte a = 200; ubyte b = 100; ubyte c = (a+b)&0xff; or something like that, so the expression is specifically proven to fit in the byte with compile time facts. `(a+b)&0xff` What is this syntax?! Could you give a link to this in the D documentation? I am not even sure how to look it up... & is the normal binary and operation, same in C, C++, Java, ... 0xFF is a hexadecimal constant (255), which the compiler knows fit in an ubyte So what do you not understand about this syntax?
Re: Can't add ubytes together to make a ubyte... bug or feature?
On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe wrote: On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend wrote: I don't care if my computer needs to do math on a 4 byte basis, I'm not writing assembly. x86 actually doesn't need to do math that way, if you were writing assembly, it would just work. This is just an annoying rule brought over by C. Can I prevent the initial implicit casts? Nope, though you can help tell the compiler that you want it to fit there by doing stuff like ubyte a = 200; ubyte b = 100; ubyte c = (a+b)&0xff; or something like that, so the expression is specifically proven to fit in the byte with compile time facts. `(a+b)&0xff` What is this syntax?! Could you give a link to this in the D documentation? I am not even sure how to look it up...
Re: Finding equivalent of C++ feature in D documentation.
On Saturday, 23 December 2017 at 15:58:27 UTC, Seb wrote: On Saturday, 23 December 2017 at 15:45:33 UTC, Mike Franklin wrote: On Saturday, 23 December 2017 at 15:04:30 UTC, kerdemdemir wrote: Is there any better way for me to search C/C++ equivalent features? As a humble suggestion would it make sense to make a table with feature names and corresponding name of the same feature in other languages ? Try this: https://wiki.dlang.org/Programming_in_D_for_C%2B%2B_Programmers ... and potentially this: https://wiki.dlang.org/Coming_From Those resources are community maintained. When I was first learning D, if I encountered a problem and struggled to a solution, I would make an attempt to documented it on the D wiki to try and save others from having to go through the same difficulty. I encourage you to do the same. Mike There are these two pages: https://dlang.org/ctod.html https://dlang.org/cpptod.html Thanks guys both pages are good. @Mike I really want to add this case about M.I.L syntax in to wiki page. But since I am not a D pro; I am shy and also I am not sure if I have the permission to modify this page. Do you suggest me to try adding this spesific to the wiki page?
Re: Finding equivalent of C++ feature in D documentation.
On Saturday, 23 December 2017 at 15:45:33 UTC, Mike Franklin wrote: On Saturday, 23 December 2017 at 15:04:30 UTC, kerdemdemir wrote: Is there any better way for me to search C/C++ equivalent features? As a humble suggestion would it make sense to make a table with feature names and corresponding name of the same feature in other languages ? Try this: https://wiki.dlang.org/Programming_in_D_for_C%2B%2B_Programmers ... and potentially this: https://wiki.dlang.org/Coming_From Those resources are community maintained. When I was first learning D, if I encountered a problem and struggled to a solution, I would make an attempt to documented it on the D wiki to try and save others from having to go through the same difficulty. I encourage you to do the same. Mike There are these two pages: https://dlang.org/ctod.html https://dlang.org/cpptod.html
Re: Finding equivalent of C++ feature in D documentation.
On Saturday, 23 December 2017 at 15:04:30 UTC, kerdemdemir wrote: Is there any better way for me to search C/C++ equivalent features? As a humble suggestion would it make sense to make a table with feature names and corresponding name of the same feature in other languages ? Try this: https://wiki.dlang.org/Programming_in_D_for_C%2B%2B_Programmers ... and potentially this: https://wiki.dlang.org/Coming_From Those resources are community maintained. When I was first learning D, if I encountered a problem and struggled to a solution, I would make an attempt to documented it on the D wiki to try and save others from having to go through the same difficulty. I encourage you to do the same. Mike
Finding equivalent of C++ feature in D documentation.
I needed to find equivalent of member initialization list in D. After searching ~10 minutes I found D has very elegant solution (https://dlang.org/spec/class.html#field-init) after reading through whole constructor page. My question is not technical this time I have my solution. But I think when I google "Member inilization in D" I am expecting to be directed to correct documentation. This unfortunately happens a lot to me. And this minutes sum into hours and inefficiency. Is there any better way for me to search C/C++ equivalent features? As a humble suggestion would it make sense to make a table with feature names and corresponding name of the same feature in other languages ? Erdem
Re: Base class' constructor is not implicitly inherited for immutable classes. A bug or a feature?
On Wednesday, 19 July 2017 at 16:00:56 UTC, Piotr Mitana wrote:
Hello, I have this code:
immutable class Base
{
this() {}
}
immutable class Derived : Base {}
void main()
{
new immutable Derived();
}
I'd like class Derived to automatically inherit the default
constructor from Base. However, this is not the case:
main.d(6): Error: class main.Derived cannot implicitly generate
a default ctor when base class main.Base is missing a default
ctor
Is it a bug or it should be like this?
compiles with:
dmd 2.073
fails with:
dmd 2.074
dmd 2.075
Re: Base class' constructor is not implicitly inherited for immutable classes. A bug or a feature?
On Wednesday, 19 July 2017 at 16:00:56 UTC, Piotr Mitana wrote:
Hello, I have this code:
immutable class Base
{
this() {}
}
immutable class Derived : Base {}
void main()
{
new immutable Derived();
}
I'd like class Derived to automatically inherit the default
constructor from Base. However, this is not the case:
main.d(6): Error: class main.Derived cannot implicitly generate
a default ctor when base class main.Base is missing a default
ctor
Is it a bug or it should be like this?
Interesting that the same code without immutable works.
Re: Base class' constructor is not implicitly inherited for immutable classes. A bug or a feature?
On Wednesday, 19 July 2017 at 16:00:56 UTC, Piotr Mitana wrote:
Hello, I have this code:
immutable class Base
{
this() {}
}
immutable class Derived : Base {}
void main()
{
new immutable Derived();
}
I'd like class Derived to automatically inherit the default
constructor from Base. However, this is not the case:
main.d(6): Error: class main.Derived cannot implicitly generate
a default ctor when base class main.Base is missing a default
ctor
Is it a bug or it should be like this?
I'd say it's a bug. There was a similar issue at one point where
it wouldn't consider default constructor with default args.
Base class' constructor is not implicitly inherited for immutable classes. A bug or a feature?
Hello, I have this code:
immutable class Base
{
this() {}
}
immutable class Derived : Base {}
void main()
{
new immutable Derived();
}
I'd like class Derived to automatically inherit the default
constructor from Base. However, this is not the case:
main.d(6): Error: class main.Derived cannot implicitly generate a
default ctor when base class main.Base is missing a default ctor
Is it a bug or it should be like this?
Re: As many thanks As possible to who crates D and UFCS feature
On Saturday, 13 May 2017 at 10:51:09 UTC, k-five wrote: Okay, and NOW I understood what you are trying to say. First of all I thought you got mad at me. And I became sad. My sincere apologies! Always assume the best in people :-) I am glad you asked for clarification. [...] Still I am a beginner and learner. I am too, and learners we are all. Thanks anyway. Welcome.
Re: As many thanks As possible to who crates D and UFCS feature
On Saturday, 13 May 2017 at 10:15:34 UTC, Bastiaan Veelo wrote: On Saturday, 13 May 2017 at 08:23:55 UTC, k-five wrote: [...] OK understood. [...] I am sorry for expressing myself poorly. What I meant to say is that it looked like you can write an interesting article about your experience learning and using C++ and learning and using D, comparing the two. D could come out of that comparison favourably considering 1) how long it takes to learn, 2) how much code you need to write, 3) whether there are difficulties along the way, and 4) how productive you can be (getting things done). I may have been jumping to conclusions, but it could still be an interesting read, especially for people that consider learning C++ or D. In particular the focus on UFCS is interesting, as that can be rather alien to beginners, and something you are enthusiastic about. [...] Understood. [...] Posting it here is fine. You could also have posted in the general forum, as it is more of a compliment than a question. But if you want to write more about your positive experience, then a blog article might be nice. It would reach more people, and it would maybe help some of them. If you want to do that work, then maybe Mike Parker would want to put it on the D blog, and help you polish it. Whatever you decide to do, thanks for sharing your experience here :-) Bastiaan. On Saturday, 13 May 2017 at 10:15:34 UTC, Bastiaan Veelo wrote: -- Okay, and NOW I understood what you are trying to say. First of all I thought you got mad at me. And I became sad. Since; I tell this really that I was so happy about the code in D, that I would want to share my happiness here with others and not expressing myself. Still I am a beginner and learner. Thanks anyway.
Re: As many thanks As possible to who crates D and UFCS feature
On Saturday, 13 May 2017 at 08:23:55 UTC, k-five wrote: On Friday, 12 May 2017 at 20:53:56 UTC, Bastiaan Veelo wrote: Is it safe to say that these 40 lines of D do the same as your 324 lines of C++ [1]? No. I cannot say that. Since this is not a full port of renrem in C++ to D. It was just an example in D, nothing else. OK understood. This, and your comments on the difficulties of building renrem [2] versus doing "rdmd", and the steepness of the learning curve (1 year C++ vs 2 weeks D), and the productivity (2 hours D vs ?? C++) I am not sure about understanding your purpose correctly. I think are plenty material for a nice little blog. Which English Grammar rule is used here? Sorry but I do not know! are: linking verb after think: main verb and subject! I am sorry for expressing myself poorly. What I meant to say is that it looked like you can write an interesting article about your experience learning and using C++ and learning and using D, comparing the two. D could come out of that comparison favourably considering 1) how long it takes to learn, 2) how much code you need to write, 3) whether there are difficulties along the way, and 4) how productive you can be (getting things done). I may have been jumping to conclusions, but it could still be an interesting read, especially for people that consider learning C++ or D. In particular the focus on UFCS is interesting, as that can be rather alien to beginners, and something you are enthusiastic about. I just want to say D is easy to learn and use; that is it. I have no arguing about which Language is better no not. Of course that program with C++, took me 1 month until it got ready, but in 2 days I could ported to D, since I had the already experience of implementing it. Understood. Mike Parker runs the D blog, and I think he might be interested. No need to worry about the english language, you are safe with Mike. I'll see if I can get you his attention. Sorry ... Still could not understand ... except you may want me to put such post in D blog not here, and in this case, your are right, the best way for such examples is on a blog or similar. Sorry for posting it here. Posting it here is fine. You could also have posted in the general forum, as it is more of a compliment than a question. But if you want to write more about your positive experience, then a blog article might be nice. It would reach more people, and it would maybe help some of them. If you want to do that work, then maybe Mike Parker would want to put it on the D blog, and help you polish it. Whatever you decide to do, thanks for sharing your experience here :-) Bastiaan.
Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 20:53:56 UTC, Bastiaan Veelo wrote: Is it safe to say that these 40 lines of D do the same as your 324 lines of C++ [1]? No. I cannot say that. Since this is not a full port of renrem in C++ to D. It was just an example in D, nothing else. This, and your comments on the difficulties of building renrem [2] versus doing "rdmd", and the steepness of the learning curve (1 year C++ vs 2 weeks D), and the productivity (2 hours D vs ?? C++) I am not sure about understanding your purpose correctly. I think are plenty material for a nice little blog. Which English Grammar rule is used here? Sorry but I do not know! are: linking verb after think: main verb and subject! --- I just want to say D is easy to learn and use; that is it. I have no arguing about which Language is better no not. Of course that program with C++, took me 1 month until it got ready, but in 2 days I could ported to D, since I had the already experience of implementing it. Mike Parker runs the D blog, and I think he might be interested. No need to worry about the english language, you are safe with Mike. I'll see if I can get you his attention. Sorry ... Still could not understand ... except you may want me to put such post in D blog not here, and in this case, your are right, the best way for such examples is on a blog or similar. Sorry for posting it here.
Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 21:26:01 UTC, Bastiaan Veelo wrote: On Friday, 12 May 2017 at 15:24:52 UTC, k-five wrote: A full version that I just added to my gitgub: https://github.com/k-five/dren You may like getopt[1] for command line argument parsing. https://dlang.org/phobos/std_getopt.html see also https://blog.thecybershadow.net/2014/08/05/ae-utils-funopt/ https://github.com/CyberShadow/ae/blob/master/utils/funopt.d
Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 15:24:52 UTC, k-five wrote: A full version that I just added to my gitgub: https://github.com/k-five/dren You may like getopt[1] for command line argument parsing. https://dlang.org/phobos/std_getopt.html
Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 15:24:52 UTC, k-five wrote:
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote:
I was waiting for a stable version of C++17 ( standard library
) to add some features of fileSystem in C++17 to my program
that wants to iterate through all files in a directory
recursively.
I was thinking how could I do for implementing that and add it
to my program.
Now after starting to learn D ( nearby 2 weeks so far ). I can
do it in 6 lines!
void main( string[] args ){
string[] all_file_name = dirEntries( ".", SpanMode.depth,
false )
.filter!( file => !file.name.matchFirst( regex( args[
1 ] ) ).empty() )
.filter!( file => ( args[ 2 ] == "-f" || args[ 2 ] ==
"-d" ? ( args[ 2 ] == "-f" ? !file.isDir : !file.isFile ) : (
!file.isSymlink ) ) )
.map!( file => file.name )
.array;
foreach( string item; all_file_name ) writeln( item );
}
./bin-file '[A-Z]$' -f ---> print all files that are matched
against [A-Z]$
./bin-file '[A-Z]$' -d ---> print all directory that are
matched against [A-Z]$
./bin-file '[A-Z]$' "anything-else" ---> print both files and
directory that are matched against [A-Z]$
I am so happy since after more than one year practicing in C++
and putting a collection more than 2000 examples of C++ on my
github, I was not sure I could do it in 6 lines.
May it is a Spam but I think it is worth it.
--
May it has worth it to be an example on how great D is, in
somewhere like, in the tour section or std.file or std.regex to
attract others.
A full version that I just added to my gitgub:
https://github.com/k-five/dren
Is it safe to say that these 40 lines of D do the same as your
324 lines of C++ [1]? This, and your comments on the difficulties
of building renrem [2] versus doing "rdmd", and the steepness of
the learning curve (1 year C++ vs 2 weeks D), and the
productivity (2 hours D vs ?? C++) I think are plenty material
for a nice little blog.
Mike Parker runs the D blog, and I think he might be interested.
No need to worry about the english language, you are safe with
Mike. I'll see if I can get you his attention.
[1] https://github.com/k-five/renrem
[2] https://github.com/k-five/renrem/blob/master/src/README.md
[3] https://dlang.org/blog/
Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote:
I was waiting for a stable version of C++17 ( standard library
) to add some features of fileSystem in C++17 to my program
that wants to iterate through all files in a directory
recursively.
I was thinking how could I do for implementing that and add it
to my program.
Now after starting to learn D ( nearby 2 weeks so far ). I can
do it in 6 lines!
void main( string[] args ){
string[] all_file_name = dirEntries( ".", SpanMode.depth,
false )
.filter!( file => !file.name.matchFirst( regex( args[
1 ] ) ).empty() )
.filter!( file => ( args[ 2 ] == "-f" || args[ 2 ] ==
"-d" ? ( args[ 2 ] == "-f" ? !file.isDir : !file.isFile ) : (
!file.isSymlink ) ) )
.map!( file => file.name )
.array;
foreach( string item; all_file_name ) writeln( item );
}
./bin-file '[A-Z]$' -f ---> print all files that are matched
against [A-Z]$
./bin-file '[A-Z]$' -d ---> print all directory that are
matched against [A-Z]$
./bin-file '[A-Z]$' "anything-else" ---> print both files and
directory that are matched against [A-Z]$
I am so happy since after more than one year practicing in C++
and putting a collection more than 2000 examples of C++ on my
github, I was not sure I could do it in 6 lines.
May it is a Spam but I think it is worth it.
--
May it has worth it to be an example on how great D is, in
somewhere like, in the tour section or std.file or std.regex to
attract others.
A full version that I just added to my gitgub:
https://github.com/k-five/dren
Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 12:56:50 UTC, drug wrote: 12.05.2017 14:58, k-five пишет: On Friday, 12 May 2017 at 11:41:57 UTC, cym13 wrote: On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote: --- also .each!writeln should be possible - Yes. Worked. Thanks
Re: As many thanks As possible to who crates D and UFCS feature
12.05.2017 14:58, k-five пишет:
On Friday, 12 May 2017 at 11:41:57 UTC, cym13 wrote:
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote:
---
Shorter:
void main( string[] args ){
dirEntries( ".", SpanMode.depth, false )
.filter!( file => !file.name.matchFirst( regex( args[ 1 ] )
).empty() )
.filter!( file => ( args[ 2 ] == "-f" || args[ 2 ] == "-d" ?
( args[ 2 ] == "-f" ? !file.isDir : !file.isFile ) : ( !file.isSymlink
) ) )
.map!( file => file.name )
.each!(string item => writeln( item ));
}
It's more memory efficient too because at no point the actual list is
stored.
-
Thanks and the correct syntax for each! is, passing a lambda. So the:
.each!(string item => writeln( item ));
is an error:
temp.d(15): Error: found 'item' when expecting ')' following template
argument list ...
and should be:
.each!( ( string item ) => writeln( item ) );
also .each!writeln should be possible
Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote: I was waiting for a stable version of C++17 ( standard library ) to add some features of fileSystem in C++17 to my program that wants to iterate through all files in a directory recursively. I was thinking how could I do for implementing that and add it to my program. Now after starting to learn D ( nearby 2 weeks so far ). I can do it in 6 lines! Thumbs up, nice post! Bastiaan.
Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 11:58:23 UTC, k-five wrote: On Friday, 12 May 2017 at 11:41:57 UTC, cym13 wrote: [...] --- [...] - Thanks and the correct syntax for each! is, passing a lambda. So the: [...] is an error: temp.d(15): Error: found 'item' when expecting ')' following template argument list ... and should be: .each!( ( string item ) => writeln( item ) ); Ah, yeah, my bad, I should have try compiling it instead of answering directly ;)
Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 11:41:57 UTC, cym13 wrote:
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote:
---
Shorter:
void main( string[] args ){
dirEntries( ".", SpanMode.depth, false )
.filter!( file => !file.name.matchFirst( regex( args[
1 ] ) ).empty() )
.filter!( file => ( args[ 2 ] == "-f" || args[ 2 ] ==
"-d" ? ( args[ 2 ] == "-f" ? !file.isDir : !file.isFile ) : (
!file.isSymlink ) ) )
.map!( file => file.name )
.each!(string item => writeln( item ));
}
It's more memory efficient too because at no point the actual
list is stored.
-
Thanks and the correct syntax for each! is, passing a lambda. So
the:
.each!(string item => writeln( item ));
is an error:
temp.d(15): Error: found 'item' when expecting ')' following
template argument list ...
and should be:
.each!( ( string item ) => writeln( item ) );
Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote:
I was waiting for a stable version of C++17 ( standard library
) to add some features of fileSystem in C++17 to my program
that wants to iterate through all files in a directory
recursively.
I was thinking how could I do for implementing that and add it
to my program.
Now after starting to learn D ( nearby 2 weeks so far ). I can
do it in 6 lines!
void main( string[] args ){
string[] all_file_name = dirEntries( ".", SpanMode.depth,
false )
.filter!( file => !file.name.matchFirst( regex( args[
1 ] ) ).empty() )
.filter!( file => ( args[ 2 ] == "-f" || args[ 2 ] ==
"-d" ? ( args[ 2 ] == "-f" ? !file.isDir : !file.isFile ) : (
!file.isSymlink ) ) )
.map!( file => file.name )
.array;
foreach( string item; all_file_name ) writeln( item );
}
./bin-file '[A-Z]$' -f ---> print all files that are matched
against [A-Z]$
./bin-file '[A-Z]$' -d ---> print all directory that are
matched against [A-Z]$
./bin-file '[A-Z]$' "anything-else" ---> print both files and
directory that are matched against [A-Z]$
I am so happy since after more than one year practicing in C++
and putting a collection more than 2000 examples of C++ on my
github, I was not sure I could do it in 6 lines.
May it is a Spam but I think it is worth it.
Shorter:
void main( string[] args ){
dirEntries( ".", SpanMode.depth, false )
.filter!( file => !file.name.matchFirst( regex( args[ 1
] ) ).empty() )
.filter!( file => ( args[ 2 ] == "-f" || args[ 2 ] ==
"-d" ? ( args[ 2 ] == "-f" ? !file.isDir : !file.isFile ) : (
!file.isSymlink ) ) )
.map!( file => file.name )
.each!(string item => writeln( item ));
}
It's more memory efficient too because at no point the actual
list is stored.
As many thanks As possible to who crates D and UFCS feature
I was waiting for a stable version of C++17 ( standard library )
to add some features of fileSystem in C++17 to my program that
wants to iterate through all files in a directory recursively.
I was thinking how could I do for implementing that and add it to
my program.
Now after starting to learn D ( nearby 2 weeks so far ). I can do
it in 6 lines!
void main( string[] args ){
string[] all_file_name = dirEntries( ".", SpanMode.depth, false
)
.filter!( file => !file.name.matchFirst( regex( args[ 1
] ) ).empty() )
.filter!( file => ( args[ 2 ] == "-f" || args[ 2 ] ==
"-d" ? ( args[ 2 ] == "-f" ? !file.isDir : !file.isFile ) : (
!file.isSymlink ) ) )
.map!( file => file.name )
.array;
foreach( string item; all_file_name ) writeln( item );
}
./bin-file '[A-Z]$' -f ---> print all files that are matched
against [A-Z]$
./bin-file '[A-Z]$' -d ---> print all directory that are
matched against [A-Z]$
./bin-file '[A-Z]$' "anything-else" ---> print both files and
directory that are matched against [A-Z]$
I am so happy since after more than one year practicing in C++
and putting a collection more than 2000 examples of C++ on my
github, I was not sure I could do it in 6 lines.
May it is a Spam but I think it is worth it.
Re: Needed return type in static method? bug or feature?
On Tuesday, March 08, 2016 14:56:06 Antonio Corbi via Digitalmars-d-learn
wrote:
> On Tuesday, 8 March 2016 at 14:13:17 UTC, Adam D. Ruppe wrote:
> > On Tuesday, 8 March 2016 at 13:40:06 UTC, Antonio Corbi wrote:
> >> Is it a feature or a bug?
> >
> > It is allowed because the "auto" keyword doesn't actually
> > required for auto functions (or variables), what you need is
> > any one of the storage classes.
> >
> > Those include static, auto, const, immutable, even pure.
> >
> > If any of them are present, the compiler knows you are writing
> > a function or declaring a variable and will infer the type.
>
> Thank's Adam!.
>
> I had figured out something like this but I couldn't find
> anything in the docs
> (http://dlang.org/spec/attribute.html#static), moreover, the
> example there:
> --8><-
> class Foo
> {
> static int bar() { return 6; }
> ...
> --8><-
>
> does mention the return type, that's what confused me.
The return type is optional so long as one of the keywords that indicates
that it's a variable or a function is there, so you can choose to put it or
not. In most cases, I think that folks put the return type on functions or
use auto, but it's up to you. Where it usually comes up is enums and
variable declarations.
- Jonathan M Davis
Re: Needed return type in static method? bug or feature?
On Tuesday, 8 March 2016 at 14:13:17 UTC, Adam D. Ruppe wrote:
On Tuesday, 8 March 2016 at 13:40:06 UTC, Antonio Corbi wrote:
Is it a feature or a bug?
It is allowed because the "auto" keyword doesn't actually
required for auto functions (or variables), what you need is
any one of the storage classes.
Those include static, auto, const, immutable, even pure.
If any of them are present, the compiler knows you are writing
a function or declaring a variable and will infer the type.
Thank's Adam!.
I had figured out something like this but I couldn't find
anything in the docs
(http://dlang.org/spec/attribute.html#static), moreover, the
example there:
--8><-
class Foo
{
static int bar() { return 6; }
...
--8><-
does mention the return type, that's what confused me.
Re: Needed return type in static method? bug or feature?
On Tuesday, 8 March 2016 at 13:40:06 UTC, Antonio Corbi wrote: Is it a feature or a bug? It is allowed because the "auto" keyword doesn't actually required for auto functions (or variables), what you need is any one of the storage classes. Those include static, auto, const, immutable, even pure. If any of them are present, the compiler knows you are writing a function or declaring a variable and will infer the type.
Needed return type in static method? bug or feature?
Hi all!
The following code compiles and works, but the static methods do
not
have a return type. It also compiles and works if the appropiate
(or auto)
return type is added to them.
-8><
import std.stdio;
class B {
int foo () { return 1; }
static sbar () { return "hi!"; }
static ibar () { return 0; }
}
void main () {
auto b = new B;
writeln (B.sbar);
writeln (B.ibar);
}
-8><--------
Is it a feature or a bug?
I've seen it being used in
https://github.com/gecko0307/dlib/blob/master/dlib/math/matrix.d
Thank's for your help!
Re: Is this a feature?
On Thursday, 21 January 2016 at 14:39:43 UTC, Adam D. Ruppe wrote: On Thursday, 21 January 2016 at 14:35:09 UTC, Sebastiaan Koppe wrote: static if (!is(SomethingUndefined!moreUndefined[0] : UndefinedThing)) Yes, the is expression returns false for undefined things because they aren't types. The standard library uses this in a lot of places to test for undefined functions, like checking for features in ranges. (The is expression has been around a lot longer than __traits btw) Thanks. I reckoned as much. Can be handy in places. But I just spend some time figuring out that I was missing an import...
Is this a feature?
module undefined;
unittest
{
static if (!is(SomethingUndefined!moreUndefined[0] :
UndefinedThing))
{
pragma(msg,"This will compile just fine!");
}
}
Re: Is this a feature?
On Thursday, 21 January 2016 at 14:35:09 UTC, Sebastiaan Koppe wrote: static if (!is(SomethingUndefined!moreUndefined[0] : UndefinedThing)) Yes, the is expression returns false for undefined things because they aren't types. The standard library uses this in a lot of places to test for undefined functions, like checking for features in ranges. (The is expression has been around a lot longer than __traits btw) Here's the relevant spec link: http://dlang.org/spec/expression.html#IsExpression "Type is the type being tested. It must be syntactically correct, but it need not be semantically correct. If it is not semantically correct, the condition is not satisfied. " syntax is forming valid *looking* names and expressions, etc. semantically correct means passing name lookups and other tests that require the compiler to understand the context. It says it needs to look right, but not necessarily anything more.
Can't add ubytes together to make a ubyte... bug or feature?
I just attempted to add one ubyte to another and store the result in a ubyte but apparently ubytes get converted to ints when being added... and converting what becomes an int becomes impossible to store in a ubyte without an explicit cast... ubyte a, b; ubyte c = a + b; // Error: cannot implicitly convert expression (cast(int)a + cast(int)b) of type int to ubyte On principal I'm not casting to fix this. I don't care if my computer needs to do math on a 4 byte basis, I'm not writing assembly. I'm really hoping this is a bug because trying to use any type other than ints is going to make for some really ugly code otherwise... Can I prevent the initial implicit casts? On the topic of complaining about casting... array lengths as ulongs is painful... any chance of an array[].lengthi being a thing?
Re: Can't add ubytes together to make a ubyte... bug or feature?
Soviet Friend píše v Út 19. 01. 2016 v 22:12 +: > I just attempted to add one ubyte to another and store the result > in a ubyte but apparently ubytes get converted to ints when being > added... and converting what becomes an int becomes impossible to > store in a ubyte without an explicit cast... > > ubyte a, b; > ubyte c = a + b; // Error: cannot implicitly convert expression > (cast(int)a + cast(int)b) of type int to ubyte > Problem is that compiler does not know that a + b would fit in ubyte. For example if a would be 200 and b would be 100 it would not fit in ubyte. But if compiler can verify it will fit it makes cast implicit. immutable ubyte a = 0; ubyte b = 0; ubyte c = a + b; or ubyte a = 0; ubyte c = a + 0; or immutable ubyte a = 1; immutable ubyte b = 5; ubyte c = a + b; works ok but immutable ubyte a = 1; ubyte b = 0; ubyte c = a + b; can't works because b could be 255 and 255 + 1 does not fit to ubyte > On principal I'm not casting to fix this. I don't care if my > computer needs to do math on a 4 byte basis, I'm not writing > assembly. I'm really hoping this is a bug because trying to use > any type other than ints is going to make for some really ugly > code otherwise... > > Can I prevent the initial implicit casts? > > > On the topic of complaining about casting... array lengths as > ulongs is painful... any chance of an array[].lengthi being a > thing? array.length is not ulong is it size_t and I do not see any problem with that, can you be more specific.
Re: Can't add ubytes together to make a ubyte... bug or feature?
On Tue, 19 Jan 2016 23:32:57 +0100, Daniel Kozak wrote: > Soviet Friend píše v Út 19. 01. 2016 v 22:12 +: >> I just attempted to add one ubyte to another and store the result in a >> ubyte but apparently ubytes get converted to ints when being added... >> and converting what becomes an int becomes impossible to store in a >> ubyte without an explicit cast... >> >> ubyte a, b; >> ubyte c = a + b; // Error: cannot implicitly convert expression >> (cast(int)a + cast(int)b) of type int to ubyte >> >> > Problem is that compiler does not know that a + b would fit in ubyte. > For example if a would be 200 and b would be 100 it would not fit in > ubyte. But if compiler can verify it will fit it makes cast implicit. This is true for all integer types. The reason this isn't in effect for other types is that most values are small (eg array lengths), and most integer types can hold the sum of two small values. But there are plenty of small values where a [u]byte can't hold their sum.
Re: Can't add ubytes together to make a ubyte... bug or feature?
On 01/19/2016 02:12 PM, Soviet Friend wrote:
> ubytes get converted to ints when being added...
It's a common feature involving all integral type in languages like C,
C++, and D:
https://dlang.org/spec/type.html#integer-promotions
> On the topic of complaining about casting... array lengths as ulongs is
> painful... any chance of an array[].lengthi being a thing?
That is a topic sometimes with hot debate without any resolution.
Chances of it being changed in D is zero. :) Luckily, it's pretty easy
in :D ;)
long lengthi(T)(T[] arr) {
import std.exception : enforce;
import std.conv : to;
// No overflow here because this comparison is performed in 'ulong'
enforce(arr.length.to!ulong < long.max);
return arr.length.to!long;
}
unittest {
import std.traits;
auto arr = [ 1, 2 ];
static assert(isSigned!(typeof(arr.lengthi)));
assert(arr.lengthi == 2);
}
void main() {
}
Ali
Re: Can't add ubytes together to make a ubyte... bug or feature?
On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend wrote: I don't care if my computer needs to do math on a 4 byte basis, I'm not writing assembly. x86 actually doesn't need to do math that way, if you were writing assembly, it would just work. This is just an annoying rule brought over by C. Can I prevent the initial implicit casts? Nope, though you can help tell the compiler that you want it to fit there by doing stuff like ubyte a = 200; ubyte b = 100; ubyte c = (a+b)&0xff; or something like that, so the expression is specifically proven to fit in the byte with compile time facts.
Re: Feature for paranoids
On Tuesday, 10 November 2015 at 13:09:09 UTC, Fyodor Ustinov wrote: Hi! Is it possible when using the "-release" indicate that this one in/out/invariant/assert should not to be disabled? WBR, Fyodor. Since assert(false) is special (cf. http://p0nce.github.io/d-idioms/#assert%28false%29-is-special) you can use the following construct to have always-on assertions: if (!cond) assert(false); instead of: assert(cond); But -release will still remove your in/out/invariant blocks.
Re: Feature for paranoids
I wouldn't recommend release mode to paranoids. I personally use `debug invariant` and `debug assert` for purely debugging code.
Re: Feature for paranoids
On Tuesday, 10 November 2015 at 20:37:00 UTC, Fyodor Ustinov wrote: assert(false) AKA assert(0) - is a part of this language that I think it is absolute evil. WBR, Fyodor. I would say it's a minor evil, that create problems by needing an explanation. At this point it has been discussed to death already.
