Re: Why can't we transpile C++ to D?

2021-06-10 Thread sighoya via Digitalmars-d-learn
On Thursday, 10 June 2021 at 15:09:02 UTC, Tejas wrote: Sorry, I'm rather ignorant when it comes to this, but why can't we use [pegged](https://github.com/PhilippeSigaud/Pegged) to transpile C++ code to D? See

Re: How to work around the infamous dual-context when using delegates together with std.parallelism

2021-05-27 Thread sighoya via Digitalmars-d-learn
On Thursday, 27 May 2021 at 12:58:28 UTC, Christian Köstlin wrote: That looks nice, but unfortunately my data for servers and users in the real world is not static but comes from a config file. Okay, but then parametrizing the static lambda with runtime parameters should work. The important

Re: How to work around the infamous dual-context when using delegates together with std.parallelism

2021-05-27 Thread sighoya via Digitalmars-d-learn
On Thursday, 27 May 2021 at 12:17:36 UTC, Christian Köstlin wrote: Can you explain me, where here a double context is needed? Because all data now should be passed as arguments to amap? Kind regards, Christian I believe D's type system isn't smart enough to see independence between context

Re: How to work around the infamous dual-context when using delegates together with std.parallelism

2021-05-27 Thread sighoya via Digitalmars-d-learn
On Thursday, 27 May 2021 at 09:58:40 UTC, Christian Köstlin wrote: I have this small program here test.d: ``` import std; string doSomething(string[] servers, string user) { return user ~ servers[0]; } void main() { auto servers = ["s1", "s2", "s3"]; auto users = ["u1", "u2", "u3"];

Re: Why is this allowed? Inheritance variable shadowing

2021-05-26 Thread sighoya via Digitalmars-d-learn
On Wednesday, 26 May 2021 at 18:58:47 UTC, JN wrote: I am not buying the "C++ does it and it's legal there" argument. A point for it is the consistency with methods which also redefine super methods as default strategy. The question is if the default strategy needs to be changed? I wouldn't

Re: How does inheritance and vtables work wrt. C++ and interop with D? Fns w/ Multiple-inheritance args impossible to bind to?

2021-05-25 Thread sighoya via Digitalmars-d-learn
On Tuesday, 25 May 2021 at 02:47:19 UTC, Gavin Ray wrote: The below seems to work at least, which is encouraging: Awesome! At least, it becomes problematic with fields in base classes, it would be nice if we could map them to @property annotated functions in D interfaces.

Re: How does inheritance and vtables work wrt. C++ and interop with D? Fns w/ Multiple-inheritance args impossible to bind to?

2021-05-24 Thread sighoya via Digitalmars-d-learn
On Monday, 24 May 2021 at 17:39:38 UTC, Gavin Ray wrote: I'd be grateful for solid information on this Here is a more informal report how it works in C++: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.4735=rep1=pdf But in the end, I think a byte code analysis is needed to be

Re: How does inheritance and vtables work wrt. C++ and interop with D? Fns w/ Multiple-inheritance args impossible to bind to?

2021-05-24 Thread sighoya via Digitalmars-d-learn
On Monday, 24 May 2021 at 17:39:38 UTC, Gavin Ray wrote: Hence why I was asking how to make D structs/classes that have compatible or identical vtables to multiply inherited objects to pass as arguments to `extern (C++)` functions. I think classes annotated with extern is your only high level

Re: ugly and/or useless features in the language.

2021-05-23 Thread sighoya via Digitalmars-d-learn
On Sunday, 23 May 2021 at 08:35:31 UTC, Tony wrote: Why is metaprogramming added features better than the same features added in the language? One is standard between entities, the other is not. Some points: - Some features aren't general enough to be added as builtin but make sense to have

Re: ugly and/or useless features in the language.

2021-05-22 Thread sighoya via Digitalmars-d-learn
On Saturday, 22 May 2021 at 13:31:45 UTC, Ola Fosheim Grøstad wrote: The D AST is not really suitable as it stands. D is a bit like C++ in this regard, there might be a minimal core language that could be distilled from it, but it would take a D3 full breaking change to get there, so it

Re: ugly and/or useless features in the language.

2021-05-22 Thread sighoya via Digitalmars-d-learn
On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote: Which parts in dlang don't you use and why ? Well, I don't like magic constructs in the language like the type of AliasSeq you can't touch. But the more general problem in D are not features per se, but how they are composed of.

Re: dlang vs crystal-language

2021-05-01 Thread sighoya via Digitalmars-d-learn
On Wednesday, 28 April 2021 at 22:41:03 UTC, Alain De Vos wrote: What are the strengths and weaknesses comparing the two languages ? I can name a strength of dlang is the working binding to tk and gtk. Just to say, Crystal is a neat language, feels like a static ruby. Strengths: - Poweful

Re: write once type?

2021-04-30 Thread sighoya via Digitalmars-d-learn
On Friday, 30 April 2021 at 13:36:10 UTC, Steven Schveighoffer wrote: I could have looped 2x over the args, and used an inner function to fetch the first one (or maybe used a staticIndexOf to get the first ColumnDef thing), and a second loop to verify all the remaining args have the same table

Re: dlang vs crystal-language

2021-04-30 Thread sighoya via Digitalmars-d-learn
On Thursday, 29 April 2021 at 22:47:08 UTC, Alain De Vos wrote: What is the importance of type-annotations in which cases. Specifying invariants which becomes very important when refactoring code. Further it aids as documentation to understand the structures behind. @X @Y @Z makes code

Re: write once type?

2021-04-30 Thread sighoya via Digitalmars-d-learn
On Friday, 30 April 2021 at 01:30:54 UTC, Steven Schveighoffer wrote: In my case, for value of a certain type in the loop, I was storing a specific field from the first one I found, and then verifying that all the other values of that type (not exactly the same type, but similar) had the

Re: write once type?

2021-04-29 Thread sighoya via Digitalmars-d-learn
On Tuesday, 20 April 2021 at 19:56:33 UTC, Steven Schveighoffer wrote: Not only that, but I may also want to keep processing the loop and do something different if the value has already been set instead of returning immediately, which necessitates a second loop. Can I ask why you require to

Re: dlang vs crystal-language

2021-04-29 Thread sighoya via Digitalmars-d-learn
On Wednesday, 28 April 2021 at 22:41:03 UTC, Alain De Vos wrote: What are the strengths and weaknesses comparing the two languages ? I can name a strength of dlang is the working binding to tk and gtk. Less type annotations, fewer guarantees, less compile performance as cons.

Re: Why many programmers don't like GC?

2021-01-14 Thread sighoya via Digitalmars-d-learn
On Thursday, 14 January 2021 at 13:08:06 UTC, Ola Fosheim Grøstad wrote: Because Java has a well defined virtual machine with lots of restrictions. So you're insisting this isn't possible in D?

Re: Why many programmers don't like GC?

2021-01-14 Thread sighoya via Digitalmars-d-learn
On Thursday, 14 January 2021 at 11:11:58 UTC, Ola Fosheim Grøstad wrote: I know your response is *tongue in cheek*, but I actually find it easier to use c++11 style memory management across the board than mixing two models. But this is already the case for C++ and Rust. Remembering the

Re: Why many programmers don't like GC?

2021-01-14 Thread sighoya via Digitalmars-d-learn
As other people already mentioned, garbage collection incurs some amount of non-determinism and people working in low level areas prefer to handle things deterministically because they think non-deterministic handling of memory makes your code slow. For example rendering in gaming gets paused

Re: Why D functions paramter can not implicit infer type of Variant?

2021-01-13 Thread sighoya via Digitalmars-d-learn
On Wednesday, 13 January 2021 at 19:38:55 UTC, Paul Backus wrote: That's what Variant is--a struct that models the universal supertype (sometimes called "Top" or "Any"). Ahh right. Good point, so it already fits.

Re: Why D functions paramter can not implicit infer type of Variant?

2021-01-13 Thread sighoya via Digitalmars-d-learn
On Wednesday, 13 January 2021 at 16:17:02 UTC, Marcone wrote: import std; void a(int b){ } void main() { Variant c = 10; a(c); // Error } Need more sugar. Two problems: 1.) Variant is library defined, compared to the language level there isn't a default strategy to choose int32 here,

Re: I want to create my own Tuple type

2021-01-12 Thread sighoya via Digitalmars-d-learn
What about this? No magic, but I don't know the performance impact. ``` import std.meta; import std.conv; template same(Types...) { static if (Types.length >= 2) { static if (is(Types[0] == Types[$ - 1])) { const same = same!(Types[1 .. $]); }

Re: [Understanding] Classes and delegate inheritance vs function pointers

2021-01-10 Thread sighoya via Digitalmars-d-learn
On Saturday, 9 January 2021 at 18:16:04 UTC, Q. Schroll wrote: This makes no sense in my head. Is there some reason I'm unable to see? And yes, I think it should work likewise for function pointers, too.

Re: [Understanding] Classes and delegate inheritance vs function pointers

2021-01-10 Thread sighoya via Digitalmars-d-learn
On Sunday, 10 January 2021 at 00:44:26 UTC, Q. Schroll wrote: Car[] cars = ...; Vehicle[] vehicles = cars; vehicles[0] = new Boat; // err... // cars[0] is a Boat now!? Now what? Do what Java does and throw an Exception? Or use const to prevent mutation? Yes, you are right: ```

Re: [Understanding] Classes and delegate inheritance vs function pointers

2021-01-09 Thread sighoya via Digitalmars-d-learn
On Saturday, 9 January 2021 at 20:20:38 UTC, Q. Schroll wrote: That's not what I mean. You copy the reference. That's not what referencing meant. Derived d = new Derived(); Base* bp = // fails const(Base) cbp = // compiles. Generally, allowing covariant assignment for the Ptr, i.e.

Re: DConf talk : Exceptions will disappear in the future?

2021-01-07 Thread sighoya via Digitalmars-d-learn
On Thursday, 7 January 2021 at 19:35:00 UTC, H. S. Teoh wrote: Whether or not something is inlined has nothing to do with what line number it was written in. Okay, I've tried it out, and it seems it isn't the problem in the binary case as the code was first compiled and the inlined, so the

Re: DConf talk : Exceptions will disappear in the future?

2021-01-07 Thread sighoya via Digitalmars-d-learn
On Thursday, 7 January 2021 at 18:12:18 UTC, H. S. Teoh wrote: If you're unfamiliar with the subject, I recommend reading a textbook on compiler construction. I already read one. Because every introduced catch block in the libunwind implementation introduces additional overhead. But only

Re: DConf talk : Exceptions will disappear in the future?

2021-01-07 Thread sighoya via Digitalmars-d-learn
On Thursday, 7 January 2021 at 14:34:50 UTC, H. S. Teoh wrote: This has nothing to do with inlining. Inlining is done at compile-time, and the inlined function becomes part of the caller. True There is no stack pointer decrementing involved anymore Also true. because there's no longer

Re: DConf talk : Exceptions will disappear in the future?

2021-01-07 Thread sighoya via Digitalmars-d-learn
On Thursday, 7 January 2021 at 10:36:39 UTC, Jacob Carlborg wrote: Swift can throw anything that implements the Error protocol. Classes, structs and enums can implement protocols. True, Swift can throw anything what implements the Error protocol. It seems the error protocol itself doesn't

Re: DConf talk : Exceptions will disappear in the future?

2021-01-06 Thread sighoya via Digitalmars-d-learn
On Wednesday, 6 January 2021 at 21:27:59 UTC, H. S. Teoh wrote: It must be unique because different functions may return different sets of error codes. If these sets overlap, then once the error propagates up the call stack it becomes ambiguous which error it is. Contrived example:

Re: DConf talk : Exceptions will disappear in the future?

2021-01-06 Thread sighoya via Digitalmars-d-learn
Citing Herb Sutter: As noted in §1.1, preconditions, postconditions, and assertions are for identifying program bugs, they are never recoverable errors; violating them is always corruption, undefined behavior. Therefore they should never be reported via error reporting channels (regardless of

Re: DConf talk : Exceptions will disappear in the future?

2021-01-06 Thread sighoya via Digitalmars-d-learn
On Tuesday, 5 January 2021 at 21:46:46 UTC, H. S. Teoh wrote: 4) The universal error type contains two fields: a type field and a context field. a) The type field is an ID unique to every thrown exception -- uniqueness can be guaranteed by making this a pointer to some static

Re: DConf talk : Exceptions will disappear in the future?

2021-01-05 Thread sighoya via Digitalmars-d-learn
Personally, I don't appreciate error handling models much which pollute the return type of each function simply because of the conclusion that every function you define have to handle errors as errors can happen everywhere even in pure functions. You don't believe me? What about memory

Re: Recursively defined matcher function

2021-01-03 Thread sighoya via Digitalmars-d-learn
On Sunday, 3 January 2021 at 18:55:58 UTC, sighoya wrote: ``` alias matcherSignature(T:matcherSignature!T) = Matcher (T[] matchers...); ``` Yet, it is right: ``` alias matcherSignature(T:matcherSignature!T) = Matcher function(T[] matchers...); ``` But it didn't work likewise, you have

Re: Recursively defined matcher function

2021-01-03 Thread sighoya via Digitalmars-d-learn
On Sunday, 3 January 2021 at 18:49:40 UTC, sighoya wrote: ``` alias matcherSignature(T:matcherSignature!T) = T (T[] matchers...); ``` Ahhh, I meant this: ``` alias matcherSignature(T:matcherSignature!T) = Matcher (T[] matchers...); `` I think we would require proper singleton types to

Re: Recursively defined matcher function

2021-01-03 Thread sighoya via Digitalmars-d-learn
On Sunday, 3 January 2021 at 18:26:44 UTC, Per Nordlöw wrote: I've tried alias Matcher = Match function(Matcher[] matchers...); but it errors as recursive alias declaration The closest thing can I think of is: ``` alias matcherSignature(T:matcherSignature!T) = T (T[] matchers...);

Re: C++ or D?

2020-12-30 Thread sighoya via Digitalmars-d-learn
On Wednesday, 30 December 2020 at 21:12:43 UTC, Ola Fosheim Grøstad wrote: (which does not work, but maybe there is some other way to express it?): See: https://forum.dlang.org/thread/ooxzbrmbrzpsefiro...@forum.dlang.org?page=1

Re: C++ or D?

2020-12-30 Thread sighoya via Digitalmars-d-learn
On Wednesday, 30 December 2020 at 18:45:03 UTC, Ola Fosheim Grøstad wrote: Some people in the D community has for a long time wanted stack-less coroutines. This is now available in C++20, and maybe D can borrow the C++ implementation for LDC? That is an interesting possibility for sure.

Re: C++ or D?

2020-12-30 Thread sighoya via Digitalmars-d-learn
On Wednesday, 30 December 2020 at 14:41:28 UTC, Ola Fosheim Grøstad wrote: Most of the statements are wrong too... "4732 features, but not a single one you actually want": wrong again, C++20 has features that people would like to see in D Could you elaborate a bit more, please? I'm

Re: How to reliably detect an alias sequence?

2020-12-27 Thread sighoya via Digitalmars-d-learn
On Sunday, 27 December 2020 at 12:23:26 UTC, Max Samukha wrote: Given a name bound to an alias sequence, what is a reliable way to detect that? import std.meta: AliasSeq; alias a = AliasSeq!int; static if () { } __traits(isSame, a, AliasSeq!a) could work but doesn't, because it flattens

Re: Get the code of any D-entity as string?

2020-12-27 Thread sighoya via Digitalmars-d-learn
On Sunday, 27 December 2020 at 14:40:01 UTC, Basile B. wrote: A more concrete example of what you are trying to achieve would allow to show the D way. What happens with your code example for the struct: ``` struct S { ulong[] a; @E(0) const int b=1; void v() const {return;}

Re: Get the code of any D-entity as string?

2020-12-27 Thread sighoya via Digitalmars-d-learn
On Sunday, 27 December 2020 at 04:13:53 UTC, Max Haughton wrote: Not possible although implementing as a __trait would be about 15 lines I think. I think that too, and it would nicely reuse the work of the compiler to parse the whole project. I think read only AST access in some form

Re: Get the code of any D-entity as string?

2020-12-27 Thread sighoya via Digitalmars-d-learn
On Saturday, 26 December 2020 at 21:45:41 UTC, Basile B. wrote: struct E {int a;} struct S { ulong[] a; @E(0) const int b; void v() const {} void v(int) const {} } string getDeclaration(T)() if (is(T == struct)) { import std.traits, std.meta; string result = "struct " ~

Re: Get the code of any D-entity as string?

2020-12-26 Thread sighoya via Digitalmars-d-learn
On Friday, 25 December 2020 at 23:04:15 UTC, Ali Çehreli wrote: I am probably misunderstanding it but there is the .stringof property for all types: T.stringof. But does stringof really print the declaration as string and not the type name itself? I found:

Get the code of any D-entity as string?

2020-12-25 Thread sighoya via Digitalmars-d-learn
I've read a bit in Dlang traits. It now has the ability to retrieve all method signatures of an overload set. Big plus from me. Is generally possible to get the declaration of a type/module/value as string in traits? I didn't have any concrete use case for it, but it would essentially

Re: C++ or D?

2020-12-25 Thread sighoya via Digitalmars-d-learn
On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote: You can use GC, you can disable it, you can use malloc, it suits all your need! Not to forget the availability of refcounted (shared) and unique ptr too in D.

Re: Why is creating of if Expressions not allowed?

2019-03-24 Thread sighoya via Digitalmars-d-learn
On Sunday, 24 March 2019 at 18:59:45 UTC, Adam D. Ruppe wrote: Think of mixin() not as pasting code per se, but pasting an AST node inside the compiler's data structures. It must be a complete node of that tree that can be substituted in. And because AST Nodes aren't expressions means you

Re: Why is creating of if Expressions not allowed?

2019-03-24 Thread sighoya via Digitalmars-d-learn
On Sunday, 24 March 2019 at 18:43:51 UTC, Paul Backus wrote: You can't return the result of a string mixin from a function. Instead, return a string from your `GenIf` function, and mix it in at the call site: string GenIf() { return "if (true) { return true; } else { return false; }"; }

Re: Why is creating of if Expressions not allowed?

2019-03-24 Thread sighoya via Digitalmars-d-learn
On Sunday, 24 March 2019 at 16:57:25 UTC, Rémy Mouëza wrote: On Sunday, 24 March 2019 at 16:18:49 UTC, sighoya wrote: Why auto GenIf()() { return mixin("if(true) { return true;} else {return false;}"); } public bool testFunction2() { GenIf!(); } gives me: onlineapp.d-mixin-3(3):

Why is creating of if Expressions not allowed?

2019-03-24 Thread sighoya via Digitalmars-d-learn
Why auto GenIf()() { return mixin("if(true) { return true;} else {return false;}"); } public bool testFunction2() { GenIf!(); } gives me: onlineapp.d-mixin-3(3): Error: expression expected, not if onlineapp.d(8): Error: template instance `onlineapp.GenIf!()` error instantiating

Re: Does D support nested Templates aka Higher Kinded Polymorphism?

2017-10-03 Thread sighoya via Digitalmars-d-learn
On Tuesday, 3 October 2017 at 15:52:52 UTC, sighoya wrote: On Tuesday, 3 October 2017 at 15:30:52 UTC, Daniel Kozak wrote: writeln(bar!(Bar,Foo,int)(Bar!(Foo,int)())); Dne 3. 10. 2017 3:55 odpoledne napsal uživatel "sighoya via Digitalmars-d-learn" <digitalmars-d-learn@

Re: Does D support nested Templates aka Higher Kinded Polymorphism?

2017-10-03 Thread sighoya via Digitalmars-d-learn
On Tuesday, 3 October 2017 at 15:30:52 UTC, Daniel Kozak wrote: writeln(bar!(Bar,Foo,int)(Bar!(Foo,int)())); Dne 3. 10. 2017 3:55 odpoledne napsal uživatel "sighoya via Digitalmars-d-learn" <digitalmars-d-learn@puremagic.com>: But when I write this to: writeln(bar!(Bar,Foo,i

Re: Does D support nested Templates aka Higher Kinded Polymorphism?

2017-10-03 Thread sighoya via Digitalmars-d-learn
But when I write this to: writeln(bar!(Bar,Foo,int)(Bar!(Foo,int))); it complains by: test.d(11): Error: template instance T!(S!int) does not match template declaration Bar(R, S) test.d(11): Error: template instance T!(S!int) does not match template declaration Bar(R, S) test.d(17): Error:

Re: Does D support nested Templates aka Higher Kinded Polymorphism?

2017-10-03 Thread sighoya via Digitalmars-d-learn
Thanks, How do I construct such a type. I don't get it done right with: struct Foo(T) { T value; } struct Bar (R,S) { R!S fooint; } T!(S!R) bar(alias T,alias S,R)(T!(S!R) v) {return v;} void main() { import std.stdio;

Re: Does D support nested Templates aka Higher Kinded Polymorphism?

2017-10-03 Thread sighoya via Digitalmars-d-learn
On Tuesday, 3 October 2017 at 12:09:04 UTC, rikki cattermole wrote: On 03/10/2017 1:05 PM, sighoya wrote: Especially, I mean something like T foo(S,T)(T i) {     ... } struct Foo(T) { T value; } T!S foo(S, alias T)(T!S v) { return v; } void main() { import

Does D support nested Templates aka Higher Kinded Polymorphism?

2017-10-03 Thread sighoya via Digitalmars-d-learn
Especially, I mean something like T foo(S,T)(T i) { ... }