Re: TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and not TypeInfo_Interface?
On Sunday, 24 December 2017 at 05:21:44 UTC, Tofu Ninja wrote:
I didn't get any response in learn for this so I will ask it
here.
TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and
not TypeInfo_Interface?
Is this correct? Or is it a bug?
Doesn't make much sense to me.
Also the following code prints false so there are some
consequences to this.
# #
import std.stdio;
void main(string[] args) {
writeln(typeid(c).interfaces[0].classinfo == typeid(i)); //
false
}
interface i {}
class c : i {}
What is the proper way to handle this mismatch?
Is this mismatch intended or just some implementation detail?
Peoples thoughts on this?
I guess I will just not get an answer to this, seems like just
some weirdness of D that will just stick there. The typeinfo
system seems really half baked and really provides very little in
terms of usefulness.
TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and not TypeInfo_Interface?
I didn't get any response in learn for this so I will ask it here.
TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and not
TypeInfo_Interface?
Is this correct? Or is it a bug?
Doesn't make much sense to me.
Also the following code prints false so there are some
consequences to this.
# #
import std.stdio;
void main(string[] args) {
writeln(typeid(c).interfaces[0].classinfo == typeid(i)); // false
}
interface i {}
class c : i {}
What is the proper way to handle this mismatch?
Is this mismatch intended or just some implementation detail?
Peoples thoughts on this?
Re: D jobs?
On Saturday, 25 November 2017 at 22:55:00 UTC, Ali Çehreli wrote: On 11/25/2017 05:16 AM, Tofu Ninja wrote: >if anyone is in the bay area and is in a position to higher I'm not in a position to hire but I know networking is very effective in finding jobs. https://www.meetup.com/D-Lang-Silicon-Valley/ Just saying... ;) Ali Oh yes, thank you that is really helpful as well. I am really glad I made this thread, I would not have thought of that.
Re: D jobs?
On Saturday, 25 November 2017 at 16:51:37 UTC, Mark wrote: On Saturday, 25 November 2017 at 13:16:19 UTC, Tofu Ninja wrote: Are there any places to look for D jobs? It seems really hard to find anything online. I got a really crappy job doing C++ and hate it to bits. Also if anyone is in the bay area and is in a position to higher maybe check out this project I have been working on in my free time, its a small game engine in D that I have been working on https://github.com/tofuninja/DGraphics. Try and convince your employer to replace C++ with D. :) Well there are a lot of other reasons I want to leave too, the place is a shit hole. I took the job thinking I would be working for NASA thought that would be cool, ended up working for the US ARMY... and I am trans. I WANT OUT.
Re: D jobs?
On Saturday, 25 November 2017 at 13:49:09 UTC, bauss wrote: On Saturday, 25 November 2017 at 13:16:19 UTC, Tofu Ninja wrote: Are there any places to look for D jobs? It seems really hard to find anything online. I got a really crappy job doing C++ and hate it to bits. Also if anyone is in the bay area and is in a position to higher maybe check out this project I have been working on in my free time, its a small game engine in D that I have been working on https://github.com/tofuninja/DGraphics. https://dlang.org/orgs-using-d.html Oh thanks, I will take a look at that.
Re: D jobs?
On Saturday, 25 November 2017 at 13:16:19 UTC, Tofu Ninja wrote: Are there any places to look for D jobs? It seems really hard to find anything online. I got a really crappy job doing C++ and hate it to bits. Also if anyone is in the bay area and is in a position to higher maybe check out this project I have been working on in my free time, its a small game engine in D that I have been working on https://github.com/tofuninja/DGraphics. Oh and forgot, here is my resume. https://drive.google.com/file/d/19CKTI7TrBHFRfKMxCfYXNkSD0MCAEl4V/view?usp=sharing
D jobs?
Are there any places to look for D jobs? It seems really hard to find anything online. I got a really crappy job doing C++ and hate it to bits. Also if anyone is in the bay area and is in a position to higher maybe check out this project I have been working on in my free time, its a small game engine in D that I have been working on https://github.com/tofuninja/DGraphics.
Status of static control flow? static foreach?
Sorry, I have not kept up in the forums for a while. Was just curious on what the current status of static control flow was for D. The only one I have heard about was static foreach, what happend, are we going to get it? We have static if, are we going to get other static control flow like static for, static while, static switch(if any of those make sense)? Thanks..
Possible range idiom that I find useful, especially in @nogc
So this is a small thing but I find it definitely useful in my
own ranges and wished the ranges in phobos did this.
A lot of ranges in phobos take an alias to a function and somehow
use that to generate the output range, for example map. But it
can be annoying when your map function needs extra data to
perform the map. Example...
auto foo(R)(R range, int x) {
return range.map!((v)=>(v+x));
}
That works perfectly well because it will allocate a closure and
make it work. But if foo was @nogc then it would fail. If you are
trying to avoid the gc, the basic range functions get pretty
annoying to use.
One thing I have started doing with any of my range generators
that take an alias to a function is to have an extra ARGS...
argument tacked in on the end. Then the range that gets generated
will save the extra args into the resulting range struct and pass
them back into the alias function whenever it needs to be called.
Example:
auto RangeGenerator(alias pred, ARGS...)(ARGS args) {
// Range struct
struct Range {
private ARGS extra;
// range implementation that somehow calls pred
// If pred is normally takes a single argument, similar
to map, like pred(item)
// then I would instead call pred(item, extra)
}
Range r;
r.extra = args;
/// any other setup
return r;
}
I use this alot, for example I have an octree implementation that
provides range interface to iterate the items that lie in a
specific region in space. The region is defined by a region
function that takes an axis aligned bounding box and returns true
or false if it lies in the region. But a lot of times the region
function needs extra arguments to do the test, but I can't rely
on gc allocated closures to make it possible. So instead I just
pass the extra data into the range generator and have it saved
into the resulting range struct. It works extremely well and
means I don't need to use the GC.
I don't know if anyone else ever has this problem but I just
thought I would share.
Re: Logical location of template instantiations
On Thursday, 7 July 2016 at 12:39:51 UTC, Steven Schveighoffer wrote: Yes, it is a problem. I still don't understand how the *calling* of a private function is the problem, vs. the aliasing of it. Why aren't we preventing the aliasing of the private function in the first place (if not allowed)? If you can get an alias, you should be able to call it. I understand that aliases are strange in this way. What we really need is an alias to the protection level. An explicit permission given to an external template that says "for this one instantiation, you can pretend you have access to this". A workaround, of course, is to use a delegate. I came across this when learning vibe.d, which gets around the requirement in an interesting way: https://github.com/rejectedsoftware/vibe.d/issues/1516 -Steve It makes sense that the aliasing a private member works, when it is made at the instantiation site it is perfectly visible. It only gets mucked up when the alias travels out of that context into the template where it is no longer visible.
Re: Logical location of template instantiations
On Friday, 1 July 2016 at 19:13:45 UTC, Steven Schveighoffer
wrote:
Emplace needs a constructor alias parameter.
-Steve
That wouldn't work as emplace wouldn't be able to use the alias
if it was private...
void main(){
import other;
test!foo();
}
private void foo(){}
##
module other;
void test(alias pred)(){
pred();
}
other.d(5): Error: function main.foo is not accessible from
module other
main.d(9): Error: template instance other.test!(foo) error
instantiating
Re: Blocking points for further D adoption
You know I just had an idea for documentation that might be nice. Why not make all the examples interactive like the "Your code here" box on the front page? We have the technology, could be cool.
Re: Is dmd fast?
On Wednesday, 6 July 2016 at 19:12:23 UTC, ketmar wrote: On Wednesday, 6 July 2016 at 08:13:01 UTC, Tofu Ninja wrote: On Wednesday, 6 July 2016 at 05:46:20 UTC, ketmar wrote: On Wednesday, 6 July 2016 at 05:38:25 UTC, Tofu Ninja wrote: dmd seems pretty fast to me. add "-O -inline" and go to bed. ;-) Went up to about 18s for a full rebuild of the project and the dub dependencies, I am ok with these times :) so you can't just start project rebuilding when you want some free hours... DMD should add some slow build mode! You could probably add something in CTFE to slow things down.
Re: Should templates have the instantiating scope's protection access rights?
On Wednesday, 6 July 2016 at 08:05:38 UTC, Lodovico Giaretta
wrote:
Thinking about this, maybe the choice about attributes should
be made by the user, so that if I want to give emplace access
to private ctors of my structs, I have to explicitly declare
inside my module that I'm going to give emplace those rights
(which in turn are propagated to whatever templates emplace
uses internally).
This way the template writer doesn't have to bother whether his
template needs those rights, it is clear which templates have
them without looking at their declarations, and users can
decide not to grant these rights (bonus point: this way nothing
changes behaviour unless the user wants so).
That is an option too. However there would still need to be some
way for the rights to get carried through multiple levels of
templates. I suppose retransmission could be done in two ways,
explicitly or implicitly. I am not sure which way would be better.
If it was explicit, things like allocator.make would need to
explicitly retransmit the access rights down to emplace.
Something like :
##
auto make(T, A, ARGS...)(A alloc, ARGS args) {
// ...
emplace!(@ShareAccess T)(/* ... */);
//...
}
// Some other module
class myClass{
private this(int x){}
}
// ...
auto x = Mallocator.make!(@ShareAccess myClass)(5);
// Access rights get transmitted into make and then make
retransmits them into emplace
##
If it was implicit the @ShareAccess in make would not be
necessary, the access rights would carry through to emplace
implicitly. I am not sure it would be a good option though
because access might get accidentally granted somewhere it
shouldn't.
Having it be opt-in by the user also resolves the range function
example I had earlier where it needed access to mypred. In this
case I think the implicit retransmission is probably better, as
it would allow any range function to not care about
retransmitting the rights if they pass the argument to other
templates.
Re: Is dmd fast?
On Wednesday, 6 July 2016 at 05:46:20 UTC, ketmar wrote: On Wednesday, 6 July 2016 at 05:38:25 UTC, Tofu Ninja wrote: dmd seems pretty fast to me. add "-O -inline" and go to bed. ;-) Went up to about 18s for a full rebuild of the project and the dub dependencies, I am ok with these times :)
Re: Should templates have the instantiating scope's protection access rights?
On Wednesday, 6 July 2016 at 06:43:13 UTC, ZombineDev wrote: Using mixin templates you can get the behavior you want to some extent, with exception that you need to type "mixin" in front when you're instantiating them. I wonder if reusing the mixin statement for normal templates would be a good idea to reuse existing code while allowing access to private members. I thought about that, but the problem affects things like emplace as well and I somehow doubt that we are going to turn emplace into a mixin template. I think there needs to be some kind of opt-in attribute to indicate that the template should use the instantiating module's access rights. There are three things it would need to do... 1) It would need to cause the template instantiation to have the same access rights as the instantiating module. 2) It would need to tie the instantiation to the instantiating module, different module will have different access rights so the templates won't match. 3) It would need to transmit these access rights through other templates if they also have the opt-in attribute. All the templates would have the instantiating scopes access rights. It would be needed in cases like allocator.make which ends up calling emplace eventually. The access rights would need to be transmitted all the way to emplace. The attribute could be argument specific or applied to the whole template, I am not sure which would be better but they could both work.
Re: Blocking points for further D adoption
On Wednesday, 6 July 2016 at 07:10:07 UTC, Puming wrote: It's been suggested that DMD/LDC/GDC could be combined into a bundle, say DCC, and when you call DCC hello.d it will call dmd hello.d, and if you call DCC -fast hello.d it will call ldc hello.d or gdc hello.d This will give newcomers a different experience. Problem with that is ldc and gdc are always a few versions behind dmd.
Re: Blocking points for further D adoption
You know what's kinda sad, there are only 2,052 question on SO with the "d" tag. I think if more d questions could be answered on SO then it would make googling d related things a lot easier. Another problem with SO is that it uses "d" instead of "dlang", "dlang" is generally better for google.
Re: Is dmd fast?
On Wednesday, 22 June 2016 at 19:56:26 UTC, Adam D. Ruppe wrote: On Wednesday, 22 June 2016 at 19:25:13 UTC, Jack Stouffer wrote: So if linking is slow, then compilation is slow. But, 1/3 second isn't slow... I don't feel compilation is slow until it takes more like 5 seconds. Certainly, 1/3s is noticable (if you do a hello world with printf instead of writeln you can feel the difference btw), but it isn't important. D compile speed typically *scales* better than the competition. Instead of chasing the 100ms in hello world, it tackles the 1ms of a real project. I have a >15000 LOC project that also depends on many dub packages and uses a fair amount of CTFE. Even doing a full rebuild, it still only takes roughly 10s. If I skip rebuilding the dub dependencies then the time is usually cut in half. Over all dmd seems pretty fast to me.
Re: Should templates have the instantiating scope's protection access rights?
On Tuesday, 5 July 2016 at 18:48:05 UTC, Tofu Ninja wrote: Also there could be code re-use wherever the access rights match. So if an argument is marked as opt-in, only the instantiation scope's access to that argument would need to be tied to the template instantiation. I suppose that means there would be 4 possible instantiations, one for private, package, protected, and public access. Actually scratch that, it would have to match on access rights to the argument and any symbol accessible through the argument. It would get even crazier on recursive instantiations, so I think you are right, the template would have to be tied to the original instantiation module. If the template instantiated any other templates that had this behavior it would also have to be tied to the original module. Sounds complicated.
Re: Should templates have the instantiating scope's protection access rights?
On Tuesday, 5 July 2016 at 18:04:31 UTC, Steven Schveighoffer wrote: The clear problem with this solution is that this means you must use the instantiating module as part of the template definition. A template instantiation with exactly the same parameters must behave exactly the same, no matter where it was instantiated from. What this means, is that each instantiation is now tied to the module instantiating it, with no code reuse. I think at the very least, this should be opt-in if it even makes sense to do. Ah that is a really good point, I knew it would muck something up. But I suppose in a lot of cases this doesn't really matter, if the template is accessing private things then it already couldn't be reused outside of the module. I think it would make a difference in cases where the template does some kind of reflection or conditional compilation based on if it has access or not. Still opt-in I think. Also there could be code re-use wherever the access rights match. So if an argument is marked as opt-in, only the instantiation scope's access to that argument would need to be tied to the template instantiation. I suppose that means there would be 4 possible instantiations, one for private, package, protected, and public access.
Should templates have the instantiating scope's protection access rights?
Sorry if this has been posted before.
One thing that constantly bugs me about D is how the protection
system works when using templates. Currently the a template
instantiation has the protection rights from the declaration
scope, but this is not really congruent with how a lot of
templates are used.
For example in phobos it is common to see something like:
module bar;
void foo(alias pred, R)(R range) { /* somehow uses pred on
the range elements */ }
Its pretty common throughout std.algorithm. However, because of
the way the protection system works, the pred that is passed in
MUST be public. For example the following code won't work:
private void mypred(RangeElementType x){ /* do something
with x */ }
...
import bar : foo;
foo!mypred(someRange);
Because foo is declared in another module, mypred MUST be public.
I am passing mypred explicitly, there is no way I didn't intend
for foo to have access to it. This causes lots of unnecessary
public functions.
An even more annoying consequence of this is that emplace can
never be used with private constructors, this fundamentally puts
it in a weaker position than new. This is actually a serious
problem for std.experimental.allocator. You can't use an
allocator in the same way you use new.
One possible solution could be that templates have the access
rights of the instantiating scope. This is honestly what I expect
most of the time but there are probably cases where this would
muck things up. Maybe a more case by case solution would be
better.
Thoughts?
Unwanted moves in d and intrusive data structures
Figured I would link this because no one responded on Reddit, I did not make the post, just linking. https://www.reddit.com/r/d_language/comments/4oohgl/unwanted_moves_in_d_and_intrusive_data_structures/
Re: [OT] Are there any jobs for D?
On Monday, 2 May 2016 at 23:32:26 UTC, Vladimir Panteleev wrote: On Monday, 2 May 2016 at 23:15:05 UTC, Brian Schott wrote: On Monday, 2 May 2016 at 23:08:02 UTC, Tofu Ninja wrote: I am going to be graduating soon and figured it would be cool to see if there were any jobs for D. Where would one look? http://wiki.dlang.org/Current_D_Use http://wiki.dlang.org/Jobs That is a depressingly short list, and none in the US. This Current_D_Use has a few more but still pretty short. I guess I won't hold my breath on using D at work, kinda sad, I really love D.
[OT] Are there any jobs for D?
I am going to be graduating soon and figured it would be cool to see if there were any jobs for D. Where would one look?
Re: aquivalent to pragma comment
On Thursday, 28 April 2016 at 16:05:39 UTC, andi wrote: aquivalent Also fyi, it should be equivalent, not aquivalent. I don't think aquivalent is an english word.
Re: Visual studio official d support
On Tuesday, 9 February 2016 at 22:11:12 UTC, Steven Schveighoffer wrote: A while ago there was a movement to get d included officially in visual studio. Just got this email: An idea you supported has been closed. Thank you for your feedback. Message: This is a great candidate for a language service extension. Moved to newly created wiki for requested extensions. https://github.com/Microsoft/vscode/wiki/Requested-Extensions Also vscode != visual studio
Re: Just because it's a slow Thursday on this forum
On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei Alexandrescu
wrote:
https://github.com/D-Programming-Language/phobos/pull/3971 --
Andrei
People one github were asking for a dump function so they could do
int a = 5;
dump!("a"); // prints "a = 5"
Here's a working version if anyone wants it but you have to use
it like
mixin dump!("a");
//
mixin template dump(Names ... )
{
auto _unused_dump = {
import std.stdio : writeln, write;
foreach(i,name; Names)
{
write(name, " = ", mixin(name), (i
Re: Just because it's a slow Thursday on this forum
On Friday, 5 February 2016 at 02:46:01 UTC, Tofu Ninja wrote: ... It's kinda neat cus it supports arbitrary expressions. Mixins are pretty powerful.
Re: [dlang.org] new forum design
On Monday, 18 January 2016 at 15:03:18 UTC, Vladimir Panteleev wrote: ... OK, I figured this one out. We weren't loading Roboto Slab Bold, so the browsers were making up what they thought bold could look like from the regular weight. https://github.com/CyberShadow/d-programming-language.org/commit/14dba780f5562bfe2affeb8c01a6655d0a705467 How does it look now? A lot better
Re: [dlang.org] new forum design
On Monday, 18 January 2016 at 14:40:58 UTC, Dicebot wrote: http://files.mstr.lv/new_forum.png Oh dear lord that looks bad, im on windows chrome and it does not look nearly that bad. That looks like the whole post was bolded.
Re: [dlang.org] new forum design
On Monday, 18 January 2016 at 10:20:13 UTC, Vladimir Panteleev wrote: ... The font looks particularly bad on the bolded thread titles in the forums. I think really any where I see bolded text it just looks bad, looks like its bleeding. Otherwise I dont mind the font. The main page looks a little jumbled, maybe section off the widgets into a bar on the side. Maybe section off the "Why D?" like you did with the gray section that has the the "your code here" box. Also it is really very bright, maybe provide a dark theme. Also I feel like the red header at the top is just 1 shade too bright, but maybe thats just me, I tend to like more muted tones.
Re: DIP83
On Friday, 15 January 2016 at 13:20:18 UTC, deadalnix wrote: Well I don't, both on OSX and linux, using the latest release. On linux I can do the addr2line dance, but on OSX I can't even do that as it require information that are gone once the program terminate. Hmmm, I'm on windows so maybe that's it, pretty odd tho.
Re: DIP83
On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote: We don't have line number in stack traces Huh? We dont have line numbers in stack traces? I have line numbers, I am using latest dmd, or are you talking about one of the other compilers?
Re: [dlang.org] new forum design - preview
On Friday, 15 January 2016 at 06:20:13 UTC, Vladimir Panteleev wrote: To match the new dlang.org design. I'm guessing you've missed the other threads? Oh we doing that again... seems like we want a website re-skin every 6 months or so. These issues have been previously discussed many times. (The conclusion summary is that since the same content needs to be available via multiple media - mailing lists / NNTP - content has to be restricted to the lowest common denominator, these features are controversial as the add bloat and noise, and we seem to be doing just fine without them). Now is not the time to discuss them, because the current effort is on the dlang.org redesign. I'm sorry, but so far you still haven't provided any useful criticism. My criticism is why are people spending more time redesigning the look of the website again... we haven't even had this one that long. There are better ways to improve the website than re-skinning it. Nothing is really changing, just the colors and layout.
Re: [dlang.org] new forum design - preview
On Friday, 15 January 2016 at 05:56:37 UTC, Vladimir Panteleev wrote: On Friday, 15 January 2016 at 05:52:51 UTC, Tofu Ninja wrote: On Wednesday, 13 January 2016 at 06:01:41 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ https://github.com/CyberShadow/DFeed/pull/51 Not an improvement at all, hurts my eyes. Unfortunately this form of criticism is not actionable. What would be more helpful (least to most): - A specific list of things that can be improved - What can be done to improve things - A mock-up image of how you would improve things - A pull request to improve things Why do people want to change the way the forums look? I quite like them the way they are now, soft on the eyes, fairly good layout. The forums main disadvantage is features, no code highlight, no formatting, no embedding content like images or videos into posts, ect. Also voting on posts/threads could be very useful to see what people agree with and what they dont. Right now we just have people replying with "+1". This could be exceptionally helpful for help/opinion request threads, the best answer would be upvoted, shit answers down voted.
Re: [dlang.org] new forum design - preview
On Wednesday, 13 January 2016 at 06:01:41 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ https://github.com/CyberShadow/DFeed/pull/51 Not an improvement at all, hurts my eyes.
Re: Complexity nomenclature
On Friday, 4 December 2015 at 03:37:10 UTC, Andrei Alexandrescu wrote: On 12/3/15 10:29 PM, Jack Stouffer wrote: On Friday, 4 December 2015 at 02:21:12 UTC, Andrei Alexandrescu wrote: On 12/03/2015 09:10 PM, Idan Arye wrote: The complexities of the operations is a property of the data structure being used. If each collection type will have it's own set of method names based on the complexity of operations on it, we won't be able to have templated functions that operate on any kind of collection(or at the very least, these functions will be really tedious to code). Your premise is right but you reach the negation of the correct conclusion. -- Andrei How so? If a singly linked list and a doubly linked list have two different method names for the same operation, then they cannot be easily templated. Took me a while to figure. There's a hierarchy of operations, e.g. if a collection implements insert, it automatically implements linearInsert. And so on. The collections framework provides these defaults, so client code that needs quick insert uses insert, whereas code that's fine with a linear upper bound uses linearInsert and captures both. Another way to look at it: in STL container-independent code is near impossible because different containers use the same signature for operations that are different (either wrt iterator invalidation or complexity). My design avoids that by giving distinct operations distinct names. Andrei This sounds really complicated to use? What are the benefits? When would a generic algorithm even need to know the complexity of the container? Also maybe a simpler idea would just be to annotate the the operations with there complexity with UDAs. That way things that really care about the complexity can get it, and those who don't can ignore it. It has the benefit of being self documenting as well.
Re: Pseudo namespaces
On Friday, 4 December 2015 at 02:24:32 UTC, Tofu Ninja wrote:
On Friday, 4 December 2015 at 02:02:48 UTC, Timon Gehr wrote:
On 12/04/2015 02:37 AM, Mike wrote:
On Friday, 4 December 2015 at 01:04:33 UTC, Idan Arye wrote:
People are going to hate me, but
http://dpaste.dzfl.pl/851d1d1f5e4b
Doesn't seem to scale to member access:
http://dpaste.dzfl.pl/37193377524c
/d649/f987.d-mixin-3(7): Error: 'this' is only defined in
non-static
member functions, not fun
Is there a way to make it work?
Mike
template namespace(string code,alias a=void){
mixin(code);
}
struct List{
int x;
alias stable = namespace!(q{
void fun(){
import std.stdio;
writeln(this.x);
}
},x);
}
void main(){
List lst;
lst.stable.fun();
}
:o)
WTF! Why does that even work! That is strait madness! When the
code gets mixed into the namespace template, x would have been
re-aliased to a, it would have made sense to write "writeln(a)"
which works as well... but "writeln(this.x)", wut, how... that
makes no sense...
WTF, some how having an alias to x passed in, brings the entire
this along with it. This works equally as well
struct List{
int x;
int y;
alias stable = namespace!(q{
void fun(){
import std.stdio;
writeln(typeid(this));
writeln(this.x + this.y);
}
},x);
}
Re: Pseudo namespaces
On Friday, 4 December 2015 at 02:02:48 UTC, Timon Gehr wrote:
On 12/04/2015 02:37 AM, Mike wrote:
On Friday, 4 December 2015 at 01:04:33 UTC, Idan Arye wrote:
People are going to hate me, but
http://dpaste.dzfl.pl/851d1d1f5e4b
Doesn't seem to scale to member access:
http://dpaste.dzfl.pl/37193377524c
/d649/f987.d-mixin-3(7): Error: 'this' is only defined in
non-static
member functions, not fun
Is there a way to make it work?
Mike
template namespace(string code,alias a=void){
mixin(code);
}
struct List{
int x;
alias stable = namespace!(q{
void fun(){
import std.stdio;
writeln(this.x);
}
},x);
}
void main(){
List lst;
lst.stable.fun();
}
:o)
WTF! Why does that even work! That is strait madness! When the
code gets mixed into the namespace template, x would have been
re-aliased to a, it would have made sense to write "writeln(a)"
which works as well... but "writeln(this.x)", wut, how... that
makes no sense...
Re: Pseudo namespaces
On Thursday, 3 December 2015 at 20:51:02 UTC, Andrei Alexandrescu
wrote:
I vaguely remembered I saw something like this a while ago:
http://dpaste.dzfl.pl/f11894a098c6
The trick could be more fluent, but it might have merit. Has
anyone explored it? Is it a viable candidate for becoming a D
idiom?
I was looking at this in conjunction with choosing a naming
convention for container functions. Some functions are "stable"
so that would be part of their name, e.g. insertStable or
stableInsert. With this, it's possible to write
lst.stable.insert.
Andrei
Honestly I feel like scoping in D is kinda broken. IMO they need
to be cleaned up a bit, with some kind of meaningful
formalization of scopes, how to interact with them properly and
what not. Also I think to do what you want with out fragile hacks
would require some type of named scope concept added to the
language.
Lots of things in the language introduce scopes, but there is no
formalization on them. Modules, packages, named template
instantiations, named mixin templates, structs, classes, unions,
and anonymous scopes with {}. But it seems like they all have
slightly different rules. There are a lot of things that have
scopes but opDispatch only works on classes and structs, why?
opDispatch is a scope thing, not a class or struct thing. Mixin
templates have weird as fuck scope rules as well, and really
should never have been added to the language. {} in a function
introduces a scope but I cant name it. In a template if it has a
member with the name as the template, the instantiation forwards
to that member, but in structs alias this servers a similar
purpose.
All these things should be related with some kind of formalized
scope concept. I should be able to do "alias scopeName = { //
scope stuff };" or "int scopeName.foo = 5;". Or in your problem,
"void stable.fun() {...}". Also any scope should be able to have
an opDispatch.
Scopes are a bit fucked up in D.
Bit of a rant, sorry..
Re: Pseudo namespaces
On Friday, 4 December 2015 at 01:09:07 UTC, Andrei Alexandrescu wrote: On 12/03/2015 08:04 PM, Idan Arye wrote: People are going to hate me, but http://dpaste.dzfl.pl/851d1d1f5e4b Win :o). -- Andrei Not win, we should feel ashamed that this is the kind of stuff you have to do.
Re: Our template emission strategy is broken
On Wednesday, 11 November 2015 at 13:08:08 UTC, David Nadlinger wrote: ... Sorry I haven't read this whole thread so maybe this has been mentioned before or not. I am not even sure if its really related to this topic, but it seemed related to me so I figured I would just post it here rather than make a new thread. ModuleInfo.localClasses doesn't list template class instances. I just ran into this(like 5 min ago) and thought it was odd. I expected it too list template instances as well so I thought it might be a bug, not really sure. Thankfully I don't really need it to list template instances of classes so it not affecting my project, but I could see it being a problem for others.
Re: Automatic method overriding in sub-classes
On Saturday, 31 October 2015 at 16:55:32 UTC, bitwise wrote:
On Saturday, 31 October 2015 at 16:38:58 UTC, bitwise wrote:
@synthesized void accept(this This)(Visitor v) {
v.visit(this);
}
I meant to remove "(this This)" as you don't need it if you can
just do "typeof(this)" in the function body.
@synthesized void accept(Visitor v) {
v.visit(this);
}
Bit
I don't particularly care what the syntax would be. I just choose
auto override because it seems to match the concept pretty well
and we already have those key words.
Re: Automatic method overriding in sub-classes
On Friday, 30 October 2015 at 21:38:40 UTC, bitwise wrote: On Thursday, 29 October 2015 at 01:14:35 UTC, Tofu Ninja wrote: On Thursday, 29 October 2015 at 00:11:06 UTC, Tofu Ninja wrote: [...] Actually never mind, what I just said was basically auto override for this() so its not really any different. And it is kinda limited with some problems. Sorry, I'm still not clear on whether or not template static this would work for you. Personally, I don't need dynamic dispatch or per-instance access. For me, as long as class info is generated per class and stored statically, that would suffice. I could always have a base method look up what it needs at runtime by type name or something. An example would be generating a serializer for a class in template static this to be used at runtime. Bit I could make it work the same way you did, but would rather a solution that did not involve a AA lookup.
Re: Automatic method overriding in sub-classes
On Thursday, 29 October 2015 at 17:32:22 UTC, Daniel N wrote: [...] class Base(T) : IBase [...] I actually did this before, I can confidently say how damn ugly and all over bad it is. Please no.
Re: Automatic method overriding in sub-classes
On Thursday, 29 October 2015 at 00:11:06 UTC, Tofu Ninja wrote: [...] Actually never mind, what I just said was basically auto override for this() so its not really any different. And it is kinda limited with some problems.
Re: Automatic method overriding in sub-classes
On Wednesday, 28 October 2015 at 21:48:36 UTC, bitwise wrote:
There is nothing spooky going on here. The declaration would be
clearly annotated with auto override, or whatever keyword was
chosen. If you were inheriting from a class, and didn't like
its auto overrides, you could manually override the functions
in your own class to stop it.
There are several discussion on these boards about using
druntime's RTInfo(T) achieve similar goals to what(I think)
we're trying to do here. This feature we're talking about
nicely dodges the issues presented by RTInfo(T), because it's
effects are localized to a single class hierarchy, instead of
trying to affect all classes universally. I'm thinking there
may be a better solution somewhere in between though.
Having the compiler turn something with template parameters
into a virtual function is a bit odd, and I don't think it will
be obvious to everyone. I think the following would suit my
needs, and may be a better solution:
class Base {
static this(this This)() { }
}
The compiler would instantiate that static constructor for
every sub class. From there, any other relevant templates could
be instantiated, and at runtime, this static ctor could stash
any relevant information in a collection under the key
'typeid(This)'. Finally, 'Base' could implement a function that
looks up the class's info by typeid(this).
I believe this solution is a great deal simpler, and less
invasive.
Bit
I could not think of a way to implement the auto override
functionality with your proposal.
But while thinking about it came up with another way that is
similar and very close to being doable now.
class Base { this(this T)(){ writeln(T.stringof); } }
class Child : Base {}
That fails to compile, but the error is in Child for not calling
the parent constructor.
Change it to:
class Base { this(this T)(){ writeln(T.stringof); } }
class Child : Base { this(){ super(); } }
And it works and the Base this(this T) gets the right T depending
on if you do new Base or new Child.
With that you could easily implement the auto override
functionality with a single function pointer in the base class.
The only thing to make it perfect would be to have the compiler
properly recognize this(this T)(){} and instantiate it for the
Child class.
I think this plus your static version could do a lot and be
pretty useful while still being pretty simple.
Re: Automatic method overriding in sub-classes
On Wednesday, 28 October 2015 at 20:04:44 UTC, Shammah Chancellor wrote: This kind of magic is detrimental to being able to reason about the code you are writing. If libraries do this for example, there's too much spooky action-at-a-distance occurring. Having explicit mixins is the appropriate way to handle this. Care to give an example?
Re: Automatic method overriding in sub-classes
On Wednesday, 28 October 2015 at 15:13:40 UTC, bitwise wrote: [...] I have to disagree with this. A function's meaning should not change because it's definition is removed. I suppose you are right. [...] A.foo() or B.foo() seems to work instead of super.super.foo() or super.foo() Ah, ok. I'll take your word for it(on my phone). I'm wondering if it would be worth it to make a DIP for this. We could sort out the details and discuss the use and ab-use cases ;) I myself would be a bit reluctant to start on the DIP right this second though, as I don't currently have the knowledge/time to back it with a proof of concept implementation. Bit Yeah I was thinking about making a dip, but lots of dips get made. Without a proof of concept implementation, most don't even get considered. I have tried to look at dmd's source but have really not been able to grok it. I sort of wish there was an article written by Walter or some one that was a intro break down of dmd internals, maybe with some examples of adding features.
Re: Automatic method overriding in sub-classes
On Tuesday, 27 October 2015 at 22:23:15 UTC, bitwise wrote:
[...]
I just did a test for this. Using dmd's -H flag to generate
header files, the bodies of member functions are removed. If
you link a static library containing the compiled class though,
everything will work, and you can still inherit the class.
[test.d]
module test;
import std.stdio;
class Test { void foo() { writeln("test"); } }
[/test.d]
[main.d]
module main;
import test;
import std.stdio;
class Derived : Test {
override void foo() { writeln("derived"); }
}
void main() {
Derived d = new Derived();
d.foo(); // prints "derived"
}
[/main.d]
With the above two files, I did this:
dmd test.d -lib -H
rm test.d #make sure dmd can't find body of foo()
dmd main.d test.a
./main
The above will print "derived".
I think dmd -H should definitely keep the definitions of auto
override functions when generating headers, but in theory,
-H also keeps the body of template functions so I would assume it
would treat auto overrides the same.
someone could remove them, and things could still work. If
someone received a static library and a D header file with
missing auto override function, they wouldn't be able to
inherit from the class, as if it were a sealed/final class.
This person, however, could work around the problem by
overriding the missing auto override function. I suppose this
is a good reason to adopt the semantics you are recommending,
where overriding an auto override function stops the automatic
behaviour, or else someone would have to override missing auto
override functions for every single level of inheritance after
the missing auto override. I suppose that if someone wanted to
resume the auto overrides, they could just override with
another auto override, and call the base class implementation
from their new override. With regards to the resuming of auto
overriding though, I'm wondering if what I am proposing is
possible in D. In C++, you can call any base method from
anywhere in a class hierarchy. In D however, it doesn't seem to
work.
I think you are correct, there is a scenario where one might want
to provide a header to a class and not include the auto override
body. An alternative solution could be that if you provide a
header to a class and don't include the auto override body, then
the auto override functionality is removed and the method is
treated as a regular method from that point on(with the most
recent version of the method being the one that is used). This
would allow the class to still be inherited later on.
[C++ ]
struct A { virtual void foo() { printf("A\n"); } };
struct B : public A { void foo() { printf("B\n"); } };
struct C : public B { void foo() { A::foo(); } };
int main() {
C c;
c.foo(); // prints "A"
}
[/C++]
In D however, the following will cause a compiler error:
"Error: identifier expected following '.', not 'super'"
[D]
class A { void foo() { writeln("A"); } }
class B : A { override void foo() { writeln("B"); } }
class C : B { override void foo() { super.super.foo(); } }
void main() {
C c = new C();
c.foo();
}
[/D]
Bit
A.foo() or B.foo() seems to work instead of super.super.foo() or
super.foo()
Re: Automatic method overriding in sub-classes
On Tuesday, 27 October 2015 at 14:47:03 UTC, bitwise wrote: [...] Going a bit further, I think you could override an auto override fun too manually as well. This would be helpful both for adding additional functionality, and as a fallback if the definition of the auto override function was not available. If someone sub classed a class in which they had manually overridden an auto override function, the compiler would fall back to using the base method, if available. Finally(pun intended), a user could manually override an auto override function and mark it as final to stop the automatic overriding. Bit Is there ever a chance the auto override definition would not be available, I think the class chain all the way up to Object always needs to be available at compile time to compile a class, so I don't see any time an auto override definition would be missing. I do like the idea of manually overriding as well if needed, but with slightly different semantics than what you said. -Manually overriding an auto override with a regular method would simply work and would stop the automatic overriding from that class on. -Overriding an auto override with another auto override would cause the new auto override to be used from that class on. -Final could still be used to stop all overriding from that class on. You could even override a normal method with an auto override and have no problems.
Re: Automatic method overriding in sub-classes
On Tuesday, 27 October 2015 at 07:52:27 UTC, Jacob Carlborg wrote:
[...]
I don't think this is possible. Think of code looking like this:
// Imagine not having access to the source code "createA"
A createA()
{
new B;
}
void inspectA(A a)
{
a.bar();
}
How should the compiler know that when instantiating/calling
"bar", T should be set to B? The compiler might not even know
about B exists at all. Even if the compiler does have access to
the complete source code it would, most likely, need to do a
full program analyze to figure out the type of T, which is
quite complicated.
The method is instantiated when the subclass is defined so T
would obviously be right on hand. Sub-classing a class with an
auto override method would implicitly instantiate and override
the method. Calling a.bar() would have no problems because bar
would be virtual.
Re: Automatic method overriding in sub-classes
On Tuesday, 27 October 2015 at 00:27:46 UTC, Tofu Ninja wrote:
...
crap, copy paste error
change the main to
void main()
{
A a = new A();
a.foo(); // prints nothing
a.bar(); // prints nothing
B b = new B();
b.foo(); // prints X
b.bar(); // prints X
A c = new B();
c.foo(); // prints nothing
c.bar(); // prints X, <--- main advantage
}
Re: Automatic method overriding in sub-classes
On Tuesday, 27 October 2015 at 00:07:36 UTC, Ali Çehreli wrote:
I don't understand all uses of the request but typeid() returns
a TypeInfo reference, which is about the actual type of an
object. The following change produces the expected output in
this case (except, it has the added module name):
void bar() { writeln(typeid(this).name); }
The output:
A
deneme.A
B
deneme.B
A
deneme.B
Ali
Here is another example
void main()
{
A a = new A();
a.foo(); // prints nothing
a.bar(); // prints nothing
B b = new B();
a.foo(); // prints X
b.bar(); // prints X
A c = new B();
a.foo(); // prints nothing
c.bar(); // prints X, <--- main advantage
}
enum uda;
class A
{
void foo(this T)()
{
import std.traits : hasUDA;
auto t = cast(T) this;
foreach(s; __traits(allMembers, T))
{
static if(hasUDA!(mixin("t." ~ s), uda))
{
writeln(s);
}
}
}
void bar(auto override this T)()
{
auto t = cast(T) this;
t.foo();
}
}
class B : A
{
@uda int x;
}
Re: Automatic method overriding in sub-classes
On Tuesday, 27 October 2015 at 00:07:36 UTC, Ali Çehreli wrote:
On 10/26/2015 04:25 PM, Tofu Ninja wrote:
##
class A
{
void foo(this T)() { writeln(T.stringof); }
void bar(auto override this T)() { writeln(T.stringof); }
}
class B : A {}
void main()
{
A a = new A();
a.foo(); // prints "A"
a.bar(); // prints "A"
B b = new B();
b.foo(); // prints "B"
b.bar(); // prints "B"
A c = new B();
c.foo(); // prints "A"
c.bar(); // prints "B" <-- main advantage, method is
virtual
}
##
I don't understand all uses of the request but typeid() returns
a TypeInfo reference, which is about the actual type of an
object. The following change produces the expected output in
this case (except, it has the added module name):
void bar() { writeln(typeid(this).name); }
The output:
A
deneme.A
B
deneme.B
A
deneme.B
Ali
For something as simple as the name, yea, type id works. But for
something like iterating over UDA's or looking at
__traits(allMembers) or something like that, type id is not what
is needed.
Automatic method overriding in sub-classes
I know this has basically no chance of ever actually being added
because that is the way of all "I want feature X" threads, but I
thought I would post this anyways because I seem to want it
constantly.
So we have TemplateThisParameters methods which are cool but have
some drawbacks.
They are templates so they are implicitly non-virtual and are
called based on the type of the reference.
It would be very nice to be able to auto generate method
overrides based on the this type with out having to drop a mixin
in every sub class.
This would be very useful for CT-reflection.
I will call this new feature auto override methods for the rest
of this post.
An auto override method would take the form of a template method
with only a single type argument that is the type of the class or
any of it's sub classes.
To differentiate it from TemplateThisParameters it could look
like:
returnType functionName(auto override this T)() {...}
When ever a class with an auto override method is sub-classed,
the auto override method template is re-instantiated with the
sub-class type and the method is overridden automatically.
Key point is that the method will still be virtual.
Here is an example contrasting an auto override method with a
regular TemplateThisParameters method.
##
class A
{
void foo(this T)() { writeln(T.stringof); }
void bar(auto override this T)() { writeln(T.stringof); }
}
class B : A {}
void main()
{
A a = new A();
a.foo(); // prints "A"
a.bar(); // prints "A"
B b = new B();
b.foo(); // prints "B"
b.bar(); // prints "B"
A c = new B();
c.foo(); // prints "A"
c.bar(); // prints "B" <-- main advantage, method is virtual
}
##
Possible uses:
-Automatic generation of nice toString.
-Auto-generate property panes. This is actually a use I need
right now, to generate property panes for entity types in a game
engine(unity style).
-Another time I needed it, I have a UI system that will
automatically apply ui formatting based on the existence of
"stylize properties" that can be read at compile time, but it
required a virtual method to have to be redefined for each
sub-class which simply reflected on the this type and checked for
the existence of the "stylize properties".
-Check if a sub-class implements certain features
-Check if sub-class has a certain UDA
etc...
I find myself needing this a lot in my code, especially as I
write a lot of CT-reflection.
So far the only way I have found to achieve this is to drop a
string mixin in every subclass putting the override in.
Thoughts?
Any one else needed this before?
Any clever way to do this now that I have not thought of?
-Tofu
core.time.Duration.get depreciation time is up
http://dlang.org/phobos/core_time.html#.Duration.get Deprecated. Please use split instead. Too frequently, get or one of the individual unit getters is used when the function that gave the desired behavior was total. This should make it more explicit and help prevent bugs. This function will be removed in June 2015. June has come and passed...
Re: Matrix API support - start with formats?
On Friday, 14 August 2015 at 18:51:51 UTC, David Nadlinger wrote: On Friday, 14 August 2015 at 15:11:39 UTC, ponce wrote: Are sparse matrices a common scenario? Yes. They tend to pop up in virtually all "serious" numerical problems in science and engineering, particularly when partial differential equations are involved. If anything I think small vectors, non-sparse matrixes and rectangles/AABB could be part of Phobos before that. If you just had a go at it from the CG/gamedev perspective, you'd probably end up with an API that is entirely unsuitable for larger problems. This might not be a big issue (just have two separate APIs), but we'd need to make it a conscious decision. — David Personally I would prefer small fixed sized vectors & matrices with game dev focused api be kept separate from a big/sparse matrix api.
Re: Matrix API support - start with formats?
On Friday, 14 August 2015 at 15:11:39 UTC, ponce wrote: On Friday, 14 August 2015 at 14:57:19 UTC, Andrei Alexandrescu wrote: I stumbled upon https://software.intel.com/en-us/node/471374 which gives good detail on Intel's Math Kernel Library's data formats for sparse matrices. No doubt other popular linear algebra libraries have similar documentation. I was thinking we could start with adding these layouts to std, along with a few simple primitives (construction, element/slice access, stride etc). Then, people may just use those as they are or link with the linalg libraries for specific computations. Thoughts? Andrei Are sparse matrices a common scenario? If anything I think small vectors, non-sparse matrixes and rectangles/AABB could be part of Phobos before that. +1
Re: Where are the semantics of shared defined?
On Thursday, 13 August 2015 at 21:29:42 UTC, rsw0x wrote: The only mention of them in the spec is: shared Attribute The shared attribute modifies the type from T to shared(T), the same way as const does. Am I missing something obvious? There is this http://dlang.org/migrate-to-shared.html But you are right, the spec is seriously lacking in details.
Re: Phobos addition formal review: std.experimental.allocator
On Thursday, 13 August 2015 at 21:05:28 UTC, rsw0x wrote: On Thursday, 13 August 2015 at 20:56:36 UTC, Tofu Ninja wrote: Something I thought about today, if a class or struct is allocated by an allocator(say a malloc based allocator) and one of its fields is populated with a reference to GCed memory, will the GC know to scan the allocator memory to keep that GCed memory alive? http://dlang.org/phobos/core_memory.html#.GC.addRange Yeah I know about that, I was just asking if all the allocators would be marked to be scanned by default. Or if they might try to only mark as needing to be scanned if they contain types that could contain references. The information of which types have internal references seems to be available at least to the GC. Theoretically an allocator could use that information to mark its allocations as needing to be scanned as well. Or it could be a wrapper allocator that simply marks things as needing to be scanned when they need to be, that way it would be an opt-in type deal. just some thoughts...
Re: Phobos addition formal review: std.experimental.allocator
Something I thought about today, if a class or struct is allocated by an allocator(say a malloc based allocator) and one of its fields is populated with a reference to GCed memory, will the GC know to scan the allocator memory to keep that GCed memory alive?
Re: new release doesn't work as advertised
On Thursday, 13 August 2015 at 10:40:08 UTC, learn wrote: trying to compile the minimal console application generated by visuald: Building Debug\ConsoleApp1.exe... LINK : fatal error LNK1104: cannot open file 'libucrtd.lib' Building Debug\ConsoleApp1.exe failed! win10 - vs2015 Sigh... another example of D's tooling holding it back/scaring away newcomers. Though the replies in this thread are probably doing a better job at scaring away newcomers.
Re: D fund
On Thursday, 13 August 2015 at 00:22:05 UTC, Adam D. Ruppe wrote: On Wednesday, 12 August 2015 at 18:19:48 UTC, Bruno Medeiros wrote: Actually, it seems BountySource is experimenting with a monthly payment model: https://salt.bountysource.com/ Invite only at the moment, but I think you can submit request if you are the project leader. Interesting, they seem to recognize the problems I have with their main service... perhaps they can become the patreon of open source if they pull this off. This is actually really cool, D needs to see if it can get on this. Andrei! Get on this! I want to give D money!
Re: DIP81: Writing files at compile time
On Thursday, 13 August 2015 at 00:58:14 UTC, JDemler wrote: On Wednesday, 12 August 2015 at 23:27:16 UTC, Tofu Ninja wrote: On Wednesday, 12 August 2015 at 18:37:40 UTC, JDemler wrote: Triggered by the original forum thread I wrote a DIP to further explain the idea of the writing files at compile time feature and its implications. http://wiki.dlang.org/DIP81 Please discuss! The benefits of this I see are debugging, actually having the generated files makes it much simpler to see what is going wrong. Otherwise the utility of this can be achieved with string mixins. A simple alternative to this would be a flag to the compiler to expand mixins and output the new files. This would also be great for tooling, an IDE could use this and allow you to expand a mixin in place to see what it looks like. And currently all the auto complete engines I have seen for D don't handle mixins very well. Expanding them would make autocompletion a simpler job. While this might work for very simple and basic mixins, with the combination of TMP and compile time reflection this becomes not only impractical but also impossible. Think again about the vibe.d example: There is one mixin handeling all the template-type combinations. How would such a mixin be expanded? The resulting code differs from template to template and from type to type. I suppose such an expansion flag would need to expand templates as well, which is still not a bad idea. Templates can be hard to follow sometimes and expanding them out in all their forms could be helpful for debugging and for tooling as well. Though there would be a lot of expansions.
Re: DIP81: Writing files at compile time
On Wednesday, 12 August 2015 at 18:37:40 UTC, JDemler wrote: Triggered by the original forum thread I wrote a DIP to further explain the idea of the writing files at compile time feature and its implications. http://wiki.dlang.org/DIP81 Please discuss! The benefits of this I see are debugging, actually having the generated files makes it much simpler to see what is going wrong. Otherwise the utility of this can be achieved with string mixins. A simple alternative to this would be a flag to the compiler to expand mixins and output the new files. This would also be great for tooling, an IDE could use this and allow you to expand a mixin in place to see what it looks like. And currently all the auto complete engines I have seen for D don't handle mixins very well. Expanding them would make autocompletion a simpler job.
Re: D fund
On Tuesday, 11 August 2015 at 14:26:45 UTC, Nick Sabalausky wrote: On 08/10/2015 01:10 PM, Tofu Ninja wrote: Would be great if D could have full time paid devs working on it. Totally. That would be a dream job @_@ I know right, where can I apply?
Re: D for Game Development
On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote: On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: [...] …[insert your language here] has a long way to go… :) Which is why I think people are attracted towards D. It's very close to being "there". The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack. I am hoping once std.allocators gets done, language support for it will get added. Some way to get new and delete to forward to specific allocators. And some way to define a scope that uses an allocator such that every thing in that scope that gets allocated uses that allocator, including allocations down the call tree.
Re: D fund
On Sunday, 9 August 2015 at 13:52:17 UTC, Andrei Alexandrescu wrote: On 8/9/15 5:15 AM, ref2401 wrote: Does the fund exist? Are there sponsors? How can one donate some money to D? There will be a possibility with the D Language Foundation, hopefully by the end of this year. -- Andrei What exactly will any funds the D foundation gets be used for? Would be great if D could have full time paid devs working on it.
Re: D fund
On Monday, 10 August 2015 at 16:58:15 UTC, vladde wrote: On Monday, 10 August 2015 at 01:34:24 UTC, Walter Bright wrote: On 8/9/2015 6:52 AM, Andrei Alexandrescu wrote: There will be a possibility with the D Language Foundation, hopefully by the end of this year. -- Andrei Looking forward to it. We can also use the foundation to sell some D swag so that people will get something for their donation. After all, nothing is cooler than wearing a D t-shirt to a C++/Java/Go/Rust convention! Will the swag feature http://dlangcomicstrips.tumblr.com/ ? Lol Wtf who makes those? They are hilarious!
Re: Writing/Creating files at compile-time
On Monday, 10 August 2015 at 07:02:44 UTC, Iain Buclaw wrote:
On 10 August 2015 at 07:54, ChangLong via Digitalmars-d
what will bing D more awesomeness is a ctfe execute.
enum file = execute("shell scripts");
I don't think so...
Its basically as bad, but the execute is frr more useful.
Re: D for Game Development
On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote: On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote: On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d I agree, and now we ship a Phobos DLL, resolving that issue. Really? Where is it? (I can't see it in the distribution). Should be in the bin directory. There is no Phobos dll, only Phobos lib.
Re: Writing/Creating files at compile-time
On Monday, 10 August 2015 at 01:57:40 UTC, ketmar wrote: next will be full filesystem access, 'cause hey, we need directory listings! and stat()! and unlink()! and wow, how can we live without http downloader?! and... this road has no end, and the problem already has a solution: preprocessing step. nothing stops you from writing your preprocessors in D and run 'em as a part of your build script. Directory listing of the string mixin directory would actually be super nice.
Re: D for Game Development
On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote: On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: ... This pretty much hit the nail on the head on why dmd needs deprecated. I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I don't care if it works on windows, it produces code slower than interpreted lua. Exactly what use is that? It may as well not work on windows at all as far as release builds are concerned. dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower. I think another point to look at is how far gdc and ldc have come while still having so few people working on them. Clearly they are able to get more done faster because they can leverage the work of the llvm and gcc devs. Seems silly that the majority of our talent is focused on dmd when it is the slowest of the bunch. D's "not made here" syndrome strikes again! Also I really wish we had 1 main editor that was "THE" D editor. Something that was officially maintained and packaged with the rest of D. VisualD is cool, but not cross platform. monoD is nice, but no windows debugging support. DDT is also nice, it says it can do debugging in windows, but I was never been able to get it to work. They all have problems. If I had to vote, I would vote for monoD or DDT as they are both the closest to being complete solutions. But one really needs to be the focus and packaged with D, make it complete and let the others die. D debugging is in a laughable state. It really sucks and it seems to not be a concern at all by the core D people. That alone is a huge problem. If only we could get a cross platform D debugger that just worked and was officially maintained. Again tooling is D's biggest problem. Just my 2c
Re: D for Game Development
On Friday, 7 August 2015 at 13:07:59 UTC, rsw0x wrote: On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu wrote: On 8/6/15 6:48 PM, Tofu Ninja wrote: I really feel like D needs to get over it's "not invented here" syndrome, a much easier path would to just use a pre existing cross platform windowing library. I agree (though I don't know much about which library would be the best choice), at least on the basis of scarce resources. Large ambitious projects are a lot more fun to start than complete. -- Andrei Bare windowing libraries that are well tested already exist, like GLFW. +1
Re: Interpreting the D grammar
On Thursday, 6 August 2015 at 23:08:01 UTC, Casper Færgemand wrote: On Sunday, 2 August 2015 at 16:37:06 UTC, MakersF wrote: Of course it's recursive! Do you want the grammar to be able to only define a finite number of programs? a* seems pretty infinite to me. :P (0|1)* Just define your language in binary, problem solved
Re: D for Game Development
On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole wrote: Here is what we need to do going forward (beyond what me and Manu are doing): 1. Derelict-Util needs to be put into Phobos. This is not optional 2. Derelict-GL3 needs to be put into Phobos. Optional, but might be a damn good idea! 3. Windows API needs to be moved into either Phobos or druntime. Not optional. 4. X11 bindings added to Phobos. Not optional. 5. Cocoa bindings added to Phobos. Not optional. This all needs to happen _before_ we start working on a window library for Phobos. Let alone a GUI. We're mostly got problems with Cocoa. X11 bindings just need to be changed to dynamically bound. Windows API bindings if gone into druntime wouldn't need to go through the review cycle luckily. But would need some decent review on e.g. Github. I really feel like D needs to get over it's "not invented here" syndrome, a much easier path would to just use a pre existing cross platform windowing library. Its laughable that the people in D want to reinvent this stuff. It's been done, just use the already working version! Why have all this great c and c++ interop if we never use it. I have the same gripe with how the experimental.image is doing image loading/saving, there are plenty of already existing image libraries that already support every image format you could ever dream of. Just use them, they will work 1000x better than any reinvention that we do here.
Re: D for Game Development
On Thursday, 6 August 2015 at 01:13:04 UTC, Meta wrote: On Thursday, 6 August 2015 at 00:05:34 UTC, Tofu Ninja wrote: One thing I would really like for D would be an opengl binding in phobos, there was some momentum a while ago to try to get graphics into phobos with Aurora, but literally nothing came of that. As I recall it wasn't for lack of trying. Binding D to the existing C++ was just too difficult, and those issues were what spurred the greater push for improving C++ compatibility. What existing c++? Wasn't Aurora supposed to be an all D solution.
Re: D for Game Development
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote: D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games? For some time I have been seeing some cool game engine being developed in the DUB repo. What more is happening? I don't see derelictSDl and derelictSFML activities much. Whatup? One thing I would really like for D would be an opengl binding in phobos, there was some momentum a while ago to try to get graphics into phobos with Aurora, but literally nothing came of that. People want an all D gui, and graphics support but literally nothing will ever happen until we at least get some basic graphics interfaces like a simple windowing library and some opengl. We are already getting color and images, full on hw supported graphics is the next step. Also a thing I would really like is if all the new graphics related things went into a std.graphics, it would be nice if it was std.graphics.color, std.graphics.image, std.graphics.opengl, std.graphics.window, std.graphics.gui, ect... That and some simple linear alg into phobos, gl3n pls? We literally have most of the needed parts already just laying around on dub and in other places.
Re: std.experimental.color, request reviews
On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote: https://github.com/D-Programming-Language/phobos/pull/2845 I'm getting quite happy with it. I think it's a good and fairly minimal but useful starting point. It'd be great to get some reviews from here. Whats the status on this? This really should be easy to move into phobos, color is hard to mess up.
Re: DMD on WIndows 10
On Monday, 3 August 2015 at 10:37:43 UTC, Kagamin wrote: On Saturday, 1 August 2015 at 04:25:07 UTC, Jonathan M Davis wrote: You know, it would be _really_ cool if there were an OS out there that was fully compliant with both the POSIX standard and ecosystem and the Win32 API such that you could run KDE, gnome, bash, zsh, etc. on it just like on Linux/FreeBSD/etc. _and_ run Windows programs on it - all as native applications. A total pipe dream really, but _man_ would that be cool... Windows does have a posix subsystem: https://msdn.microsoft.com/en-us/library/cc772343.aspx How well does that work?
Re: DMD on WIndows 10
On Sunday, 2 August 2015 at 17:07:39 UTC, Timon Gehr wrote: On 08/01/2015 12:02 AM, Paul D Anderson wrote: p.s. Please don't tell me how much better your favorite operating system is than Windows. Thank you. :) There are plenty operating systems that are not my favourite, yet still much better than Windows. Just couldn't restrain your self eh?
Re: Rant after trying Rust a bit
On Friday, 31 July 2015 at 09:37:10 UTC, Jonathan M Davis wrote: On Friday, 31 July 2015 at 04:47:20 UTC, Enamex wrote: Right now docs say that `delete` is getting deprecated but using it on DMD .067.1 gives no warnings. There are no warnings because it hasn't actually been deprecated yet. So, the docs are quite correct. They say that it's _going_ to be deprecated, not that it has been deprecated. Ideally, it would have been deprecated quite some time ago, but without the custom allocators, it's a lot harder to do something similar to what delete does. So, if we'd actually deprecated it, we'd have done so without a viable alternative (it's possible without custom allocators, but it's hard to get right). Now, I think that the reality of the matter that it hasn't been deprecated is simply because no one has gotten around to it yet, but there are problems with deprecating it prior getting customer allocators. Fortunately, it looks like we will soon have that in std.experimental, so it will become more reasonable to deprecate delete, and maybe we can finally deprecate it and start moving it out of the language. But it's been planned for ages that delete would be removed from D at some point. - Jonathan M Davis I would much rather delete to stay and rig it up so new and delete call the global allocator(which would be the GC by default).
Re: Interfaces, traits, concepts, and my idea for a DIP
On Wednesday, 29 July 2015 at 20:26:53 UTC, Tofu Ninja wrote:
If you write:
@satisfies!(isInputRange, MyRange) struct MyRange { ... }
the UDA can check it self, it really works as expected. Which
is why I suggested a way to get whatever the UDA is attached to
automatically in my other post.
A UDA can reference the thing it's being attached to with no
problems.
For example, this works 100% as expected right now...
@UDA!testS struct testS // UDA fails to instantiate because testS
is not an inputRange!
{
}
template UDA(alias a)
{
import std.range;
static assert(isInputRange!a);
}
The only thing that would be needed to make this a nice solution
is some syntax sugar to automatically get whatever the UDA is
attached to, which is why I suggested this:
template UDA(alias a = __UDA_ATTACHMENT__) { ... }
Re: Interfaces, traits, concepts, and my idea for a DIP
On Wednesday, 29 July 2015 at 14:51:52 UTC, Atila Neves wrote:
On Wednesday, 29 July 2015 at 08:25:04 UTC, Roland Hadinger
wrote:
On Tuesday, 28 July 2015 at 12:49:17 UTC, Atila Neves wrote:
So... instead of having traits / concepts, what I wanted from
D is to be able to do this:
struct MyRange: isInputRange { ... }
+1
or
struct MyRange: static isInputRange { ... } // that way
classes could do this too
What about this instead:
@satisfies(isInputRange) struct MyRange { ... }
which is not as terse, but maybe less confusing, because
intuitively ':' could be mistaken to mean 'extends'.
'static' has too many meanings already for my taste. I really
don't like it when frequently used keywords are reused to mean
different things in slightly different places.
That looks nice, but who's going to check it? UDAs have to be
reflected on to well, do anything. At least a template mixin
will cause a static assert to fail.
Atila
If you write:
@satisfies!(isInputRange, MyRange) struct MyRange { ... }
the UDA can check it self, it really works as expected. Which is
why I suggested a way to get whatever the UDA is attached to
automatically in my other post.
Re: Points of Failure
On Tuesday, 28 July 2015 at 22:55:03 UTC, H. S. Teoh wrote: On Tue, Jul 28, 2015 at 10:41:55PM +, Adam D. Ruppe via Digitalmars-d wrote: On Tuesday, 28 July 2015 at 22:28:17 UTC, H. S. Teoh wrote: >A lot of his points are highly subjective, e.g., I don't see >why having a web viewer for the source control system is so >absolutely important that it's worth 5 points of FAIL. Do >people seriously read through source code on a web viewer (as >opposed to, say, git cloning it and looking at it / building >it locally)?! Yes, I do it all the time. I'm often interested in just one small file and don't want to download dozens of megabytes of irrelevant garbage to get to them. I see. So this is one of those things where I do thing differently from everybody else, I guess? Man, do I feel old... ;-) T Hah yeah, even when I have the source to phobos on my hard drive, I still often opt to just read some random file in github because it takes me fewer clicks to get open.
Re: Interfaces, traits, concepts, and my idea for a DIP
On Tuesday, 28 July 2015 at 13:23:37 UTC, Daniel Kozák wrote:
I was thinking about same many times before. With one
difference:
instead of this:
struct MyRange: isInputRange { ... }
I would use something like this:
@interface(InputRange, ...)
struct MyRange { ... }
@interface(InputRange, ...)
class MyClassRange { ... }
I have actually thought about this as well, and a thing that
could actually make this possible is if UDAs could get the thing
they are attached to. I realized it could be done easily when I
saw that this worked:
template someuda(alias attach) {}
@someuda!(x) int x;
someuda can even inspect x and see itself attached to it, pretty
cool. Only thing that would be needed to make it seamless is a
for a new default arg value identifier like __FILE__ that just
translates to whatever the UDA is attached to. I would call it
__UDA_ATTACHMENT__. So the above would be translated to:
template someuda(alias attach = __UDA_ATTACHMENT__) {}
@someuda!() int x;
The parens would sadly still be necessary, but then you could do:
import std.range.interfaces;
template StaticInterface(alias Iface, alias attach =
__UDA_ATTACHMENT__)
if(is(Iface == interface))
{
// See if attach statically implements Iface
}
@StaticInterface!(InputRange)
struct someRange {...}
Re: force inline/not-inline
On Tuesday, 28 July 2015 at 13:30:52 UTC, Marc Schütz wrote: On Tuesday, 28 July 2015 at 12:46:25 UTC, Adrian Matoga wrote: On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote: "tcak" wrote in message news:psflpqqpsukpfgpzh...@forum.dlang.org... Why not like pragma(inline, [try | force | no]) ? Walter liked the boolean version, which is certainly better than nothing. I regret I missed this pull request and the chance to vote for "always"/"never" proposed by yebblies, which hit the right neurons in reader's brain instantly, unlike the generic true/false. Someone made this exact suggestion in the PR, but as happens with most sensible suggestions, it was shot down. I feel like that is becoming a trend for D, lately it feels like the only things that end up making its way into the language are dirty hacks.
Re: Last call for AliasSeq
On Tuesday, 28 July 2015 at 11:52:32 UTC, David Nadlinger wrote: On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote: Nothing in your post gives us a clue which kind of name would be better. In particular, it doesn't show that `AliasSeq` is any better than `TypeTuple`. So we're changing it from a bad name to one that could be even worse, for all we know. Neither do we know anything about the other alternatives. It seems you and deadalnix actually have useful evidence that can answer these questions, but neither of you posted them. Please do! What sort of evidence are you hoping for? — David We know which is most popular :) So far the only concrete "evidence" that any one has is the poll. Every thing else is just speculation and anecdotes. No one else has bothered to collect any other evidence.
Re: Last call for AliasSeq
On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote: Sorry, but this is unhelpful. All you are saying here is that "TypeTuple" is bad. Yes, but we already know that. Everyone agrees on that. The real question is: _What exactly_ is the problem with TypeTuple? The "Type" part of the name? The "Tuple" part? The combination? Maybe it's not the name at all, but the concept, or only some part of its behaviour? Nothing in your post gives us a clue which kind of name would be better. In particular, it doesn't show that `AliasSeq` is any better than `TypeTuple`. So we're changing it from a bad name to one that could be even worse, for all we know. It seems you and deadalnix actually have useful evidence that can answer these questions, but neither of you posted them. Please do! Honestly when I first was learning D, the Type part of TypeTuple was the part messed me up. I had a rough idea what a tuple was though never need to use one, so the Tuple part seemed to make sense to me, but the Type part always confused the crap out of me.
Re: Rant after trying Rust a bit
On Monday, 27 July 2015 at 19:11:53 UTC, deadalnix wrote: That is completely unmaintainable. I really don't get how the mess of unittests, mock data types, template constraints, and type interfaces that are just convention(ranges are just a convention, they don't exist anywhere) is supposed to some how be more maintainable than a single system that can serve the function of all of them and forces them all to be in sync 100% of the time. Seriously...
Re: Last call for AliasSeq
On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis wrote: Because the decision is not going to be made based on a popularity contest, and many of the folks who have been discussing this have not voted in that poll. Also, there is no clear winner in the poll anyway. AliasTuple is slightly ahead, but remember that _5_ was the top, not 3. So, the ones at the "top" of the list are far from being universally liked. AliasTuple in particular has serious issues with it from the perspective of teaching people what it is an how to use it, because it has Tuple in its name, and the construct in question is not actually a tuple (in addition to being easily confused with std.typecons.Tuple). This has been shown time and time again with TypeTuple. On technical merit, AliasSeq is one of the better choices; it was what TypeTuple had been changed to prior to the recent, large discussion on it; and none of the new suggestions are better enough to win any kind of consensus. At this point, for it to be changed, Walter and Andrei need to step in and choose something else. Otherwise, it's just going to stay AliasSeq, and it will be final, because we're not changing it again after 2.068 goes out. But thus far, they haven't changed it and have let it stay as AliasSeq, and the window of time for them to change it is shrinking fast. Regardless, even if the decision were to be made based on the poll, it would be Walter and Andrei making that decision, because it is abundantly clear that the community is unable to come to a consensus on this. - Jonathan M Davis Just food for thought, the difference between the rating of AliasTuple and AliasSeq is the same as the difference between AliasSeq and TypeTuple
Re: [RFC] std.experimental.concepts
On Sunday, 26 July 2015 at 15:24:45 UTC, Andrei Alexandrescu wrote: On 7/25/15 7:25 PM, deadalnix wrote: On Saturday, 25 July 2015 at 22:09:08 UTC, Andrei Alexandrescu wrote: On 7/25/15 5:24 PM, deadalnix wrote: On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy. We could have both (i.e. add traits to D), but would we want to? -- Andrei Yes. Most template code would benefit from it. For the same reason that being able to bypass the type system is important, you also would like that most of the code don't. I think we disagree here. It doesn't seem to me that adding features to D is helpful at this point. -- Andrei I think thats valid, D is already too big. I for one would actually be more happy if some things were removed, rather than added. Template specialization and template constraints for one could probable be folded into the same thing. Structs vs Classes is weird. The default GC. Properties also being kinda weird. Lots of little warts. Always hoping for a D3. It has become my HL3 for programming languages, it wont ever happen, but I still hope. And if it did, it would be the most glorious thing ever.
Re: [RFC] std.experimental.concepts
On Sunday, 26 July 2015 at 02:18:34 UTC, Tofu Ninja wrote: Also having both basically destroys walter's augment about it getting tedious adding constraints at the top level. Having both would mean its opt-in. Just noticed I wrote augment instead of argument...
Re: [RFC] std.experimental.concepts
On Saturday, 25 July 2015 at 23:25:27 UTC, deadalnix wrote: On Saturday, 25 July 2015 at 22:09:08 UTC, Andrei Alexandrescu wrote: On 7/25/15 5:24 PM, deadalnix wrote: On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy. We could have both (i.e. add traits to D), but would we want to? -- Andrei Yes. Most template code would benefit from it. For the same reason that being able to bypass the type system is important, you also would like that most of the code don't. Also having both basically destroys walter's augment about it getting tedious adding constraints at the top level. Having both would mean its opt-in.
Re: Rant after trying Rust a bit
On Sunday, 26 July 2015 at 00:31:48 UTC, Jonathan M Davis wrote:
I see two issues here, both of which relate to maintenance. The
first one is that if the language were actually able to check
that you missed a requirement in your template constraint (like
you're suggesting) and then give you an error, that makes it
way easier to break valid code. Take code like this, for example
auto foo(T)(T t)
if(cond1!T && cond2!T)
{
...
auto b = bar(t);
...
}
auto bar(T)(T t)
if(cond2!T)
{
...
}
foo calls bar, and it does have all of bar's constraints in its
own constraints so that you don't end up with a compilation
error when you pass foo something that doesn't work with bar.
Now, imagine if bar gets updated, and now its
auto bar(T)(T t)
if(cond2!T && cond3!T)
{
...
}
but foo's constraint isn't updated (e.g. because foo is in a
different library or program that depends no bar, so the person
who updates bar isn't necessarily the same person who maintains
foo). If the compiler then caught the fact that foo didn't
check all of bar's constraints and gave an error, that would
alert anyone using foo that foo needed to be updated, but it
would also mean that foo would no longer compile, when it's
quite possible that the argument passed to foo does indeed pass
bar's template constraint and will work just fine with foo. So,
working code no longer compiles when there's no technical
reason why it couldn't continue to work. Presumably, once the
maintainer of foo finds out about this, they'll update foo, and
the problem will be fixed, but it still means that every time
that the template constraint for bar is adjusted at all, every
template that uses it risks breaking if the compiler insists
that those templates check all of bar's constraints.
I think one of the key points, is that it would be opt-in.
Current constraints would continue to work as they do now. Only
templates that chose to use the new tighter constraints would
have this "problem". They would be separate from current
constraints (with a separate syntax). Code using current
constraints would not stop working if a template that used the
new constraints.
It makes sense when you consider how current constraints work
now, they basically say "If you can't do X then fail" but they
say nothing about if it can do extra things in addition to X.
So for example in the following code I will use the
specialization syntax to signify one of the NEW constraints and
the regular "if" syntax for the current constraints.
void foo(T)(T x) if(cond1!T) // OLD constraint
{
bar(x);
}
void bar(T : cond2)(T x) // NEW constraint
{
...
}
Would still work, and would only fail when foo gets instantiated
with a type that does not pass both cond1 and cond2. Which makes
perfect sense in the context of how the current constraints work.
They only test if you can do something, they don't care if you
can do extra things. There would be no need to update the
constraints on foo.
So, yes. it does help ensure that users of foo don't end up
with error messages inside of foo thanks to foo's template
constraint not listing everything that it actually requires,
but it also breaks a lot of code when template constraints
change when the code itself will often work just fine as-is
(particularly since the change to bar that required a change to
its template constraint would usually be a change to its
implementation and not what it did, since if you changed what
it did, everyone that used it would be broken anyway). Code
that's actually broken by the change to bar will fail bar's new
template constraint even if the compiler doesn't complain about
foo (or any other function) not having updated its constraint,
and it'll still get caught. The error might not be as nice,
since it'll often be in someone else's templated code, but
it'll still be an error, and it'll still tell you what's
failing. So, with the current state of affairs, only code
that's actually broken by a change to bar's template constraint
would be broken and not everyone, whereas what you're
suggesting would break all code that used bar that didn't
happen to also check the same thing that bar was now checking
for.
With what I said about opt-in I think every thing above is null.
The key advantage to the new constraints would be that it
constrains the type to only do what the constraints say. As
opposed to being able to do anything in addition to what the
constraints say.
The second issue that I see with your suggestion is basically
what Walter is saying the problem is. Even if we assume that we
_do_ want to put all of the requirements for foo - direct or
indirect - in its template constraint, this causes a
maintenance problem. For instance, if foo were updated to call
another function
auto foo(T)(T t)
if(cond1!T && cond2!T && cond3!T && cond4!T)
{
...
auto b = bar(t);
...
auto c = baz(t);
...
}
auto
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 22:54:07 UTC, deadalnix wrote: This unitest argument is becoming ridiculous. Unless some strong argument is brought to the table that this differs from the "dynamic typing is not a problem if you write unitest" we we all should know is bogus at this point, it can't be taken seriously. +1000
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 10:01:43 UTC, Walter Bright wrote:
Phew, finally, someone understands what I'm talking about! I'm
really bad at explaining things to people that they aren't
already familiar with.
I'm not sure, but I suspect this problem may cripple writing
generic library functions that do one operation and then
forward to the next (unknown in advance) operation in a chain.
It also may completely torpedo Andrei's Design By Introspection
technique.
Actually I don't think the problem you state is actually a
problem at all, even disregarding my previous argument(which is
still think is valid). The key point is that it would be opt-in
and it would trickle down, not up. Normal templates without the
concept/traits/interface things would still be able to call
functions with the extra constraints with out needing to add it
to them selves.
For instance, say the syntax to specialize on one of these
concept/traits/interface things was the same as specializing on a
class, eg:
void foo(T : inputRange)(T x){}
Calling foo from any where would still be the same, even calling
it from other templates with out the concept/traits/interface
things. eg the following would work:
void bar(T)(T x){ foo(x); }
Because bar is a normal template, it still has no choice but to
assume that T can do any thing we ask it to do, because that is
what we have always done with templates. So the template happily
assumes that passing x into foo will work. If for some reason you
pass a type in that is not an inputRange, then it will fail at
instantiation. So far it is the same as the constraints we have
now.
Ok, here is where it is different.
In side of foo, it would be illegal to do anything other than
inputRange stuff with x. For instance the following would be
illegal:
void foo(T : inputRange)(T x)
{
x.something(); // ERROR!
}
The real kicker here, is that THAT error can be detected without
ever instantiating foo. No need to rely on unittests, which may
or may not catch it depending on which types we use.
Ok now take it a step further. Say we have the following:
void foo(T : inputRange)(T x)
{
bar(x); // ERROR!
}
void bar(T : someOtherInterface)(T x){}
The previous would error! Why? Because foo only assumes x can do
inputRange things, and when you pass it into bar it asks it to do
someOtherInterface which it doesn't know it can do! This all
would still error with out every instantiating the template!
Also the following should also error:
void foo(T : inputRange)(T x)
{
bar(x); // ERROR!
}
void bar(T)(T x) if(isSomeOtherInterface!T) {}
Why? Because from inside foo, it is only assumed that x can do
inputRange things, when it gets passed into bar the constraint
will ask it to do non inputRange things and fail! Still with out
foo being instantiated! Even something like the following should
error:
void foo(T : inputRange)(T x)
{
bar(x); // ERROR!
}
void bar(T)(T x) { x.something_inputranges_dont_have(); }
This would error for the same reasons as before, bar asked x to
do non input range things. In contrast the following would be ok!
void foo(T : inputRange)(T x)
{
bar(x); // Ok
}
void bar(T)(T x) { foreach(i;x){} }
That still works because it is known that x can do inputRange
things, so its ok! Woo!
This is awesome right? All these errors being caught without ever
instantiating the templates. You should still instantiate them
and test them, but the value is that the errors were caught
sooner, with out even instantiating them.
The main difference here is that a normal template assumes that a
type can do anything until it actually gets instantiated. Add
some constraints(the normal ones we have now) and you can filter
for things that don't do X, but you still assume that the type
can do any thing else in addition to X. On the other hand, the
concept/traits/interface things would be as conservative as
possible and only assume a type can do what its
concept/traits/interface things say it can do.
In summery, the concept/traits/interface things would not require
them to applied to the whole tree. Doing so would break how
templates work now and really just does not make sense unless
things were being redone from scratch. They are opt-in! In
addition to that, they catch a bunch of bugs in templates before
they are ever instantiated! This is a good thing.
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 09:40:52 UTC, Walter Bright wrote: if the template body uses an interface not present in the type and not checked for in the constraint, you will *still* get a compile time error. But only if the template gets instantiated with a bad type. Unit tests don't catch every thing and have to be written properly. A proper type system should catch it.
