Re: debug public release private
On Monday, 25 July 2016 at 04:58:55 UTC, Gorge Jingale wrote:
debug mixin("public"); else mixin("private");
Perhaps you could build a patched DMD which ignores 'private'.
Then when you want to compile with -debug, use this custom DMD,
and use the standard DMD the rest of the time.
I imagine it'd be a pretty simple patch, but I'm not certain.
Re: Static ternary if
On 07/24/2016 07:15 PM, Gorge Jingale wrote:
Is there a static ternary if?
(A == B) ? C : D;
for compile type that works like static if.
The way to force an expression at compile time is to use it for
something that's needed at compile time. For example, you can initialize
a manifest constant (enum) with that expression:
void main() {
enum i = (__MODULE__.length % 2) ? 42 : 43;
pragma(msg, i);
}
Instead of enum, you can use 'static const' as well.
Ali
debug public release private
debug mixin("public"); else mixin("private");
Doesn't work.
It's nice to have public members when debugging because they show
up in the debugger and one can access internals for checking. One
can enable per line using debug but it requires lots of duplicate
code.
Is there any easy way to do this?
Re: Randomized unittests
On Monday, 25 July 2016 at 02:36:04 UTC, Chris Wright wrote: On Mon, 25 Jul 2016 01:49:25 +, Gorge Jingale wrote: [...] http://code.dlang.org/packages/unit-threaded @Values() annotation on a unittest takes a range. Base that on a range that yields random values and Bob's your uncle. That range may need to be a compile-time constant. If so, it will be a little awkward to create, and you can ping Atila about possibly creating a @ValuesFrom annotation that will take a method or lambda that yields a range of values. Thanks, looks nice, a bit confusing but seems pretty useful. But why is Bob my uncle? ;)
Re: Randomized unittests
On Mon, 25 Jul 2016 01:49:25 +, Gorge Jingale wrote: > Is there any leverage in the D library for doing randomized unit > testing? Testing things with a range of possibilities instead of fixed. > Each time the test is ran a different version is executed. > This provides more coverage. > > How does one create a random number at compile time? Is this the only > way: > > http://dpaste.dzfl.pl/668646ce6d71? http://code.dlang.org/packages/unit-threaded @Values() annotation on a unittest takes a range. Base that on a range that yields random values and Bob's your uncle. That range may need to be a compile-time constant. If so, it will be a little awkward to create, and you can ping Atila about possibly creating a @ValuesFrom annotation that will take a method or lambda that yields a range of values.
Static ternary if
Is there a static ternary if? (A == B) ? C : D; for compile type that works like static if.
Randomized unittests
Is there any leverage in the D library for doing randomized unit testing? Testing things with a range of possibilities instead of fixed. Each time the test is ran a different version is executed. This provides more coverage. How does one create a random number at compile time? Is this the only way: http://dpaste.dzfl.pl/668646ce6d71?
Re: mixin template hide
On Sunday, 24 July 2016 at 18:38:53 UTC, Eppason wrote:
The obvious solution is to refactor Bar, but in the real world,
it is much harder and life would be much easier if I could
remove foo from exists inside S. At worse, if Bar did depend on
foo, I would simply get errors about missing foo.
I doubt it is possible, but maybe some tricks?
you could define a flag for foo, like:
mixin template BAR(bool addFoo = true)
{
mixin FOO;
static if(addFoo)
{
void foo(){}
}
}
mixin template hide
I use self-introspection and have the case for having to "remove"
things from the mixin.
Typically the mixin will mixin stuff that it does not exist in
the scope it is trying to mix in, a great feature.
But what I would like to do is tell the mixin not to mix in
foo(), this allows me to take a step back in the abstraction that
I have created, rather than having to only move forward.
mixin FOO();
@disable FOO.foo(); // prevents foo from mixing in from FOO and
does not add foo to the method table
with functions, I can create dummy functions, but they then still
exist. For fields, I cannot remove.
mixin template FOO()
{
void test()
{
// Self introspection
static if (__traits(compiles, foo()))
...
}
}
mixin template BAR()
{
mixin FOO();
void foo() { }
}
struct S
{
mixin BAR();
// We now have foo(); But I don't want!!!
}
You might gander that I could just mixin FOO and void this
problem. Well, there are things in BAR I do want. I do know,
because of design, that removing foo won't "break" bar, so there
is no risk. It is more risk to create a dummy foo that doesn't do
what FOO expects of it(which, is to foo).
For example, if foo is actually allocate_memory, then Foo works
with allocate_memory or without(because of self-introspection).
Bar adds the ability to allocate_memory, and print "Hello". For
S, I want FOO & the ability to print "Hello" but not the ability
to allocate.
The obvious solution is to refactor Bar, but in the real world,
it is much harder and life would be much easier if I could remove
foo from exists inside S. At worse, if Bar did depend on foo, I
would simply get errors about missing foo.
I doubt it is possible, but maybe some tricks?
Re: Transform/Compile to C/CPP as a target
On Saturday, 23 July 2016 at 19:20:10 UTC, Jacob Carlborg wrote: On 2016-07-23 14:27, ParticlePeter wrote: Is there any kind of project or workflow that converts D (subset) to C/CPP ? No idea about the status but: https://github.com/adamdruppe/tools/blob/dtoh/dtoh.d Thanks, I am looking into this, but I think its still not that what I am searching, it seems to create only C/CPP headers for D libs. I would like to have the whole source code transformed.
Calling methods under gdb.
Hello everyone! I want to contribute some project, but I have inconvenient things related to debug. My high level of using GDB is show a variable and get type of a variable. In C++ usually I use QtCreator and debugging was pretty. In Python I have PDB, that can evaluate code. In D I have just GDB. Maybe I don't understand power of GDB, but it is so inconvenient for me. So can you help me? I don't know how to call any method. I can't call method, object's method or template method. I've tried command `call`, but I get message `No symbol "func" in current context`. Although I stand under line, where this method is called. Regards.
Re: Cannot compare object.opEquals is not nogc
On Sunday, 24 July 2016 at 15:41:55 UTC, Lodovico Giaretta wrote: On Sunday, 24 July 2016 at 15:28:53 UTC, Jonathan Marler wrote: Whoa wait a second...I didn't know you could do this. I thought everything had to inherit from the object class. Can you share the syntax to define a class that doesn't derive from object? Currently, you cannot. Everything inherits from Object. I personally think this is not the best idea. But it's not that horrible either, so probably not worth a big change. But you can just ignore it. You can put on your opCmp all the attributes you want and forget about it inheriting from Object. You can decide to never write a method that takes Object. Always take the root of your sub-hierarchy, so that you know what attributes you have. If it derives from Object or not, nobody cares as long as your sub-root overrides all opXXX with new (even abstract) declarations that have @nogc. This is one of those problems that are going to have pros and cons either way you go. It's the balance between generality which yields facilities for sharing code, and specificity which inhibits shared code. Templates provide an interesting middle ground for this by allowing you to instantiate an infinite number of implementations that will fit wherever you want on this spectrum. But templates don't work with virtual methods :( Just spitballing here, but why weren't the methods on the Object class defined in interfaces instead? interface Hashable; interface Comparable; interface Stringable; I'm sure there's some big drawback to designing it this way, but the reason is escaping me at the moment. Can someone enlighten me? (Note: if a feature like this (http://forum.dlang.org/post/mrtgipukmwrxbpayu...@forum.dlang.org) was implemented, the interfaces could still provide default implementations)
Re: Cannot compare object.opEquals is not nogc
On Sunday, 24 July 2016 at 15:31:28 UTC, lqjglkqjsg wrote: Almost off topic but I've recognized a typical error here, I think that many of us have already seen it too. You develop a nice class. You put attributes everywhere @safe pure nothrow @nogc. Yay the unittest pass. Later you use it for real and you realize then that the attributes must be removed because you can't do anything in the overriden methods. That's why I'm against putting @nogc on Object. You must only annotate specific sub-hierarchies that you know will never need the GC (or whatever: @system, impure, throwing). This often means that you can only annotate closed hierarchies. This is correct: you must not annotate open ended classes unless you decide that you really NEED (NEED != WANT) these limitations. And your users will probably find them restrictive, so you need a compelling reason that cannot be solved in other ways.
Re: Cannot compare object.opEquals is not nogc
On Sunday, 24 July 2016 at 15:28:53 UTC, Jonathan Marler wrote: Whoa wait a second...I didn't know you could do this. I thought everything had to inherit from the object class. Can you share the syntax to define a class that doesn't derive from object? Currently, you cannot. Everything inherits from Object. I personally think this is not the best idea. But it's not that horrible either, so probably not worth a big change. But you can just ignore it. You can put on your opCmp all the attributes you want and forget about it inheriting from Object. You can decide to never write a method that takes Object. Always take the root of your sub-hierarchy, so that you know what attributes you have. If it derives from Object or not, nobody cares as long as your sub-root overrides all opXXX with new (even abstract) declarations that have @nogc.
Re: Singletons importing each other?
On Sunday, 24 July 2016 at 15:07:20 UTC, Jack wrote:
Is there a way for singletons that import each other, use each
other's functions?
Like i.e:
--
module sing1;
import sing2;
final class Singleton_1{
static this{
instance = new Singleton_1();
}
static Singleton_1 getInstance(){
return instance;
}
void foo(){
writeln("Sample");
}
void bar2(){
Singleton_2.getInstance().bar();
}
private:
static Singleton_1 instance;
}
---
module sing2;
import sing1;
final class Singleton_2{
static this(){
instance = new Singleton_2();
}
static Singleton_2 getInstance(){
return instance;
}
void bar(){
Singleton_1.getInstance().foo();
}
private:
static Singleton_2 instance;
}
without triggering the "cycle between modules with
constructors/destructors"?
- You can use a 3rd module that imports the two that "cycle".
- You can use another singleton implementation that doesn't rely
on a static this. e.g a kind of "lazy factory" that control the
uniquness.
Re: Cannot compare object.opEquals is not nogc
On Sunday, 24 July 2016 at 15:09:53 UTC, Lodovico Giaretta wrote: Yes, making them @nogc would require all existing overrides to be changed (overrides cannot throw away attributes, but must specify them explicitly as in the parent class, or stricter). The real problem making these @nogc is that with the current state of things @nogc implies nothrow, thus preventing exceptions (of course we should work to change this thing, and I'm personally researching convenient ways of doing it; I'll soon write a post on General about this). Remember that comparison of complex objects may require normalization, which may change the objects themselves and allocate memory. Also, comparisons may throw exceptions that need the GC (see above). So I'm personally against making those methods @nogc. But I'm also against a singly-rooted hierarchy. Removing Object and having multiple class hierarchies would entirely solve the issue. But please note that you can already "do" that: if you never use Object, but always subclasses, the fact that Object isn't @nogc is no longer an issue. While Object (if it exists) must support any kind of descendant (and thus cannot pose arbitrary limitations like @nogc is), the roots of domain-specific hierarchies can exploit the fact that they are domain-specific to impose meaningful limitations, based on the expected usage and behaviour, and can thus be @nogc. And you can either limit your algorithm inputs to objects of a specific hierarchy or, if you want it generic, use a template (read as: you don't use Object explicitly, as if it doesn't exists). Almost off topic but I've recognized a typical error here, I think that many of us have already seen it too. You develop a nice class. You put attributes everywhere @safe pure nothrow @nogc. Yay the unittest pass. Later you use it for real and you realize then that the attributes must be removed because you can't do anything in the overriden methods.
Re: Cannot compare object.opEquals is not nogc
On Sunday, 24 July 2016 at 15:09:53 UTC, Lodovico Giaretta wrote:
Remember that comparison of complex objects may require
normalization, which may change the objects themselves and
allocate memory.
Sure but this case will be the exception. If an application
really needs this they can implement their own normalizedEquals?
It wouldn't work with the comparison operators, but I don't
really like to use those comparison operators for classes anyway
since they do waaay to much in most cases:
https://github.com/dlang/druntime/blob/master/src/object.d#L136
auto opEquals(Object lhs, Object rhs)
{
// If aliased to the same object or both null => equal
if (lhs is rhs) return true;
// If either is null => non-equal
if (lhs is null || rhs is null) return false;
// If same exact type => one call to method opEquals
if (typeid(lhs) is typeid(rhs) ||
!__ctfe && typeid(lhs).opEquals(typeid(rhs)))
/* CTFE doesn't like typeid much. 'is' works, but
opEquals doesn't
(issue 7147). But CTFE also guarantees that equal
TypeInfos are
always identical. So, no opEquals needed during CTFE.
*/
{
return lhs.opEquals(rhs);
}
// General case => symmetric calls to method opEquals
return lhs.opEquals(rhs) && rhs.opEquals(lhs);
}
...Also, comparisons may throw exceptions that need the GC (see
above). So I'm personally against making those methods @nogc.
Definitely true. One thing to note is that toHash is nothrow.
Whether or not this is too restrictive is definitely up for
debate, but also making opCmp/opEquals nothrow wouldn't be the
worst thing in the world. Of course at this point, it would
likely break ALOT of code, so probably not worth it pragmatically.
But I'm also against a singly-rooted hierarchy. Removing Object
and having multiple class hierarchies would entirely solve the
issue. But please note that you can already "do" that: if you
never use Object, but always subclasses, the fact that Object
isn't @nogc is no longer an issue.
Whoa wait a second...I didn't know you could do this. I thought
everything had to inherit from the object class. Can you share
the syntax to define a class that doesn't derive from object?
P.S.
Talking about throwing exceptions in @nogc is preaching to the
choir :)
https://forum.dlang.org/post/ubtlemuqisxluxfts...@forum.dlang.org
I've explored this issue as well, I came up with a way to throw
exceptions allocated on the NonGC heap, but to clean up memory
the catcher needs to do something to dereference the exception so
it gets cleaned up. There is a DIP for natively supporting
reference counted memory, I don't remember it, but it would allow
such things to be safe to use.
Re: Cannot compare object.opEquals is not nogc
On Sunday, 24 July 2016 at 14:54:11 UTC, Jonathan Marler wrote: I believe Rufus was only referring to the virtual methods defined in the object class. That would be: toHash (Note: this is already nothrow, that's intersting and quite restrictive) opCmp opEquals I think all 3 of these are good candidates for @nogc. However, AFAIK, making them @nogc would break any code that implements them because they would have to add the @nogc attribute to their implementations (unless I am mistaken? Do subclass overrides need to explicitly have @nogc if the parent class does?). If adding @nogc is not required in the implementation, then the only code that would break would be implementations that actually do allocate GC memory. Some would think that restricting GC usage inside these virtual methods is a good thing because it has the benefit of discouraging memory allocation for these types of operations. Really, you probably shouldn't be allocating memory to perform a comparison. If you really need to, you can either allocate non GC memory, or use a different mechanism then the opCmp/opEquals methods. Yes, making them @nogc would require all existing overrides to be changed (overrides cannot throw away attributes, but must specify them explicitly as in the parent class, or stricter). The real problem making these @nogc is that with the current state of things @nogc implies nothrow, thus preventing exceptions (of course we should work to change this thing, and I'm personally researching convenient ways of doing it; I'll soon write a post on General about this). Remember that comparison of complex objects may require normalization, which may change the objects themselves and allocate memory. Also, comparisons may throw exceptions that need the GC (see above). So I'm personally against making those methods @nogc. But I'm also against a singly-rooted hierarchy. Removing Object and having multiple class hierarchies would entirely solve the issue. But please note that you can already "do" that: if you never use Object, but always subclasses, the fact that Object isn't @nogc is no longer an issue. While Object (if it exists) must support any kind of descendant (and thus cannot pose arbitrary limitations like @nogc is), the roots of domain-specific hierarchies can exploit the fact that they are domain-specific to impose meaningful limitations, based on the expected usage and behaviour, and can thus be @nogc. And you can either limit your algorithm inputs to objects of a specific hierarchy or, if you want it generic, use a template (read as: you don't use Object explicitly, as if it doesn't exists).
Singletons importing each other?
Is there a way for singletons that import each other, use each
other's functions?
Like i.e:
--
module sing1;
import sing2;
final class Singleton_1{
static this{
instance = new Singleton_1();
}
static Singleton_1 getInstance(){
return instance;
}
void foo(){
writeln("Sample");
}
void bar2(){
Singleton_2.getInstance().bar();
}
private:
static Singleton_1 instance;
}
---
module sing2;
import sing1;
final class Singleton_2{
static this(){
instance = new Singleton_2();
}
static Singleton_2 getInstance(){
return instance;
}
void bar(){
Singleton_1.getInstance().foo();
}
private:
static Singleton_2 instance;
}
without triggering the "cycle between modules with
constructors/destructors"?
Re: Cannot compare object.opEquals is not nogc
On Sunday, 24 July 2016 at 09:03:04 UTC, Lodovico Giaretta wrote: On Sunday, 24 July 2016 at 02:17:27 UTC, Rufus Smith wrote: [...] Now you are telling me to "program by trust", because there's nothing ensuring that I remember to free everything I allocated with malloc/free, while a GC would guarantee no memory leaks. Again there's nothing stopping me from returning pointers to things allocated on the stack. And now there are lots... Before you told me that programming by trust is a wrong attitude, and now you propose me to use it, risking memory leakage in a function that may be executed hundreds of times per second. [...] No. If you put a big @nogc attribute on Object.opXXX, then nobody can write GC code in his classes. So if everything is @nogc, you cannont write GC code, because it woudn't interact with Phobos. Example: if you mark an algorithm that takes a delegate @nogc, then you cannot pass GC delegates to it. So you cannot use it in GC code. [...] Yes. All building blocks must be as much @nogc as possible. But customization points (virtual functions, delegate arguments, ...) must not be @nogc, otherwise it is no possible to have classes that use the GC or callbacks that use the GC. [...] I still don't understand why you want Object.opXXX @nogc. As I already said, you can still make your functions @nogc, just accepting parameters of @nogc types. It's obvious. If I wrote a wonderful library that uses the GC, you will not use it. If I have a class that uses the GC in opXXX (and I am free to have it, because maybe I need it, and maybe it's the most efficient way for my use case), you will not use it. The same applies here. You'll have your algorithms work only on classes that declare opXXX as @nogc. Not all memory allocation patterns are good for malloc/free. Not all of them are good for stack allocations. Some of them are not even good for reference counting. Every class shall use the best solution for its job. And everybody must still be able to extend the base class. If you want to use a method specific to a subclass, you downcast. If you want to use the @nogc opXXX when the base does not enforce it, you downcast. It's the same principle: more advanced functionalities require more derived types (and @nogc is more derived, because it is covariant to not-@nogc). Basic OOP. I believe Rufus was only referring to the virtual methods defined in the object class. That would be: toHash (Note: this is already nothrow, that's intersting and quite restrictive) opCmp opEquals I think all 3 of these are good candidates for @nogc. However, AFAIK, making them @nogc would break any code that implements them because they would have to add the @nogc attribute to their implementations (unless I am mistaken? Do subclass overrides need to explicitly have @nogc if the parent class does?). If adding @nogc is not required in the implementation, then the only code that would break would be implementations that actually do allocate GC memory. Some would think that restricting GC usage inside these virtual methods is a good thing because it has the benefit of discouraging memory allocation for these types of operations. Really, you probably shouldn't be allocating memory to perform a comparison. If you really need to, you can either allocate non GC memory, or use a different mechanism then the opCmp/opEquals methods.
Re: Modules
On Sunday, 24 July 2016 at 02:45:57 UTC, rikki cattermole wrote: On 24/07/2016 2:28 PM, Rufus Smith wrote: NM, ignore. Seems it was something else going on. Although, if you know how how dmd resolves this stuff exactly, it would be nice to know. Does it just use the module names regardless of path or does the path where the module is located have any play(assuming they are properly passed to the compiler). My understanding is this: 1. For each file passed, use supplied module name 2. If an import is unknown look at each of the directories passed via -I and find it based upon a/b/c.d for module a.b.c; 3. For each file passed, if an import is unknown try to guess based upon paths Of course rdmd adds another level of behavior on top and is mostly based upon the third one. If in doubt, try using dub. It can show you all this without looking at code ;) The thing I remember being confused about was that you had to use the -I option to specify what root level module directories you want to import from AND in the file that is being imported you have to explicitly put the module name at the top of the file. In both cases, the error message you get usually doesn't make it obvious what you've done wrong. I think if you forget to put the module name at the top of the file you'll end up with a very generic message like "can't import module y". Note that this only takes care of compilation, and doesn't include how to make sure linking works. If you need more info on that let me know. For your example: foo bar x baz y baz.d(package) If you had a module inside the y directory, you would need to include the root level path for the y package like this: foo/bar/x> dmd main.d -I../baz Then each module you want from y, should be imported explicitly like this: import y.coollib; import y.awesomeutil; If you want to import multiple files from y using "import y;", then there needs to be a package.d file inside the y directory: foo/baz/y/package.d: public import y.coollib; public import y.awesomeutil; The library may or may not have a package.d file. If it does not, then each module is probably meant to be imported independently. Also if you really need to know what's going on, you can find the source code that finds imports in dmd here(I just happen to know this because I just made a PR modifying this code): https://github.com/dlang/dmd/blob/master/src/dmodule.d#L48 Hope this helps. I do remember being confused about how all this worked a few years ago but now it all makes sense. Not sure if this information is easy to find or not, if it's not, it should be added somewhere.
Re: extract .manglof of template with lambda parameters
On Sunday, 24 July 2016 at 06:03:59 UTC, Nicholas Wilson wrote:
so I have a main as follows
int main(string[] args)
{
int a = 3;
map!((int x) => x*x)((GlobalPointer!int()),a);
return 0;
}
I want to get the mangleof of the generated call to map but
without referencing it in the .o and then pass the mangleof to
another function. the call to map must still be instantiated.
How do I do this?
So I found std.traits.mangledName, but this still leaves a
problem of that I can't get the symbol map!((int x) => x*x)
without attempting to call it.
Re: Cannot compare object.opEquals is not nogc
On Sunday, 24 July 2016 at 02:17:27 UTC, Rufus Smith wrote: This just isn't right. What your saying is that because someone screwed up, we must live with the screw up and build everyone around the screw up. This mentality is why everyone is so screwed up in the first place, do you not see that? And I think you really have a misconception about the GC vs nogc. One can rewrite GC code, such as an GC based opEquals, without limitations. They can allocate on the stack, use malloc and free when done, etc. opEquals generally doesn't have state. So you it is possible to around around. It's probably always possible to rewrite a GC opEquals to use nogc without too much difficulty. Now you are telling me to "program by trust", because there's nothing ensuring that I remember to free everything I allocated with malloc/free, while a GC would guarantee no memory leaks. Again there's nothing stopping me from returning pointers to things allocated on the stack. And now there are lots... Before you told me that programming by trust is a wrong attitude, and now you propose me to use it, risking memory leakage in a function that may be executed hundreds of times per second. BUT, it is impossible to use a GC opEquals in nogc code! This means there is no work around. What you claim is that we accept the impossiblity(which makes nogc useless) just to avoid having to rewrite some GC opEquals code. We can't rewrite the nogc side, it's set in stone. We are screwed from the start when we attempt to do nogc code because at some point we will have to do comparisons. It's the same problem with purity and any other transitive relationship. All "workarounds" are just as limited because basically we added the relationship if A is nogc and A uses B, then B must be nogc. Yet, we start with B is GC. Hence we never ever have A use B, because A's can only use nogc. To see it simpler, What if everything in D was GC based. All code was marked GC(even statements, types, etc). Do you agree that nogc would be absolutely useless? We couldn't build up anything because we couldn't include any code. This is the extreme case. Conversely, if everything was built up using nogc, we could write GC based code just fine, could we not? No. If you put a big @nogc attribute on Object.opXXX, then nobody can write GC code in his classes. So if everything is @nogc, you cannont write GC code, because it woudn't interact with Phobos. Example: if you mark an algorithm that takes a delegate @nogc, then you cannot pass GC delegates to it. So you cannot use it in GC code. Therefore, claiming that we stay with GC based code just prevents using more and more nogc code. The more GC based code D gets, the less useful nogc gets and we are back were we started. Since nogc is more critical in the foundational layers, as it affects everything built on it, all core features should be nogc. This way, the user isn't can decide when to break away from the GC code, which will only affect everything after that point. Yes. All building blocks must be as much @nogc as possible. But customization points (virtual functions, delegate arguments, ...) must not be @nogc, otherwise it is no possible to have classes that use the GC or callbacks that use the GC. This is a one way street, pretending it is two way only enriches the lawyers and eventually makes everyone unhappy. Making the D dependent on the GC was a mistake that many wasted man hours will go in to trying to unravel. Trying to carry on this mistake just wastes more hours. I understand that it is a mess, but it got that way from the mistake in the first place, not from trying to undo the mistake(which is illogical because there would be no nogc if there wasn't a gc in the first place). I also understand that there is some desire to keep things "backwards compatible". This is also a mistake, not only does it prolong the pain and suffering but is irrational. 1. A fork can be made. Those people that have based their code on the GC can continue using an older version. Their code works at that point, does it not? So just stop going down that dead end path. They have what they need, it's not like they will lose anything(virtually nothing except in most cases). Moving in the correct direction is always better, regardless of who's panties get in a wad. I still don't understand why you want Object.opXXX @nogc. As I already said, you can still make your functions @nogc, just accepting parameters of @nogc types. It's obvious. If I wrote a wonderful library that uses the GC, you will not use it. If I have a class that uses the GC in opXXX (and I am free to have it, because maybe I need it, and maybe it's the most efficient way for my use case), you will not use it. The same applies here. You'll have your algorithms work only on classes that declare opXXX as @nogc. Not all memory allocation patterns are good for malloc/free. Not all of them
Re: Default implementations in inherited interfaces
On Sunday, 24 July 2016 at 07:54:11 UTC, Jonathan Marler wrote: On Thursday, 21 July 2016 at 13:37:30 UTC, Saurabh Das wrote: On Thursday, 21 July 2016 at 12:42:14 UTC, Adam D. Ruppe wrote: On Thursday, 21 July 2016 at 09:41:27 UTC, Saurabh Das wrote: Java 8 has a 'default' keyword that allows interfaces to provide a default implementation and sub-classes can optionally override it if needed. The rationale behind it was extending interfaces without causing old code to faill. (called "virtual extension methods" or "defender methods"). The use case is similar to above. Is there a way to achieve an equivalent functionality in D? Thanks, Saurabh What an interesting technique. I've never seen this before. Maybe a DIP is in order? I think it would be low priority relative to the current work being done, but this technique seems like a good thing to support in the language. I first heard about this technique (or similar) in this post by Jim Nelson about the Vala language: https://blogs.gnome.org/jnelson/2011/11/01/a-few-of-my-favorite-vala-things-interface/ Antonio
Re: Default implementations in inherited interfaces
On Thursday, 21 July 2016 at 13:37:30 UTC, Saurabh Das wrote: On Thursday, 21 July 2016 at 12:42:14 UTC, Adam D. Ruppe wrote: On Thursday, 21 July 2016 at 09:41:27 UTC, Saurabh Das wrote: Java 8 has a 'default' keyword that allows interfaces to provide a default implementation and sub-classes can optionally override it if needed. The rationale behind it was extending interfaces without causing old code to faill. (called "virtual extension methods" or "defender methods"). The use case is similar to above. Is there a way to achieve an equivalent functionality in D? Thanks, Saurabh What an interesting technique. I've never seen this before. Maybe a DIP is in order? I think it would be low priority relative to the current work being done, but this technique seems like a good thing to support in the language.
Re: extract .manglof of template with lambda parameters
On Sunday, 24 July 2016 at 06:03:59 UTC, Nicholas Wilson wrote:
so I have a main as follows
int main(string[] args)
{
int a = 3;
map!((int x) => x*x)((GlobalPointer!int()),a);
return 0;
}
I want to get the mangleof of the generated call to map but
without referencing it in the .o and then pass the mangleof to
another function. the call to map must still be instantiated.
How do I do this?
the mangled name of the call to map is
_D8dcompute5tests4test51__T3mapS40_D4main4mainFAAyaZ9__lambda2FNaNbNiNfiZiZ3mapFNaNbNiNfS8dcompute5types7pointer18__T7PointerVki1TiZ7PointeriZv
But how do I get it at compile time?
extract .manglof of template with lambda parameters
so I have a main as follows
int main(string[] args)
{
int a = 3;
map!((int x) => x*x)((GlobalPointer!int()),a);
return 0;
}
I want to get the mangleof of the generated call to map but
without referencing it in the .o and then pass the mangleof to
another function. the call to map must still be instantiated.
How do I do this?
Re: Cannot compare object.opEquals is not nogc
On Sunday, 24 July 2016 at 02:17:27 UTC, Rufus Smith wrote: On Saturday, 23 July 2016 at 22:48:07 UTC, Lodovico Giaretta wrote: [...] This just isn't right. What your saying is that because someone screwed up, we must live with the screw up and build everyone around the screw up. This mentality is why everyone is so screwed up in the first place, do you not see that? [...] I pretty much agree and had the same thoughts you've expressed here Rufus. Your arguments are logical and make sense. However, I can already tell you this kind of a change is going to elicit alot of negative feedback. I think you're gonna find yourself frustrated in a losing battle trying to get the community to see reason. I hope Im wrong, but know you got me on your side.
