Re: Researcher question – what's the point of semicolons and curly braces?
Another thing is that some people (like me) likes to shape the code as they wish, some classic examples being : f(arg1, arg2, arg3); return predicate() ? a : b;
Re: Logo for DlangScience
On Saturday, 9 April 2016 at 10:16:36 UTC, 9il wrote: Hello, Where I can find old and new D logo from dlang.org in svg format? Can I use them as basis for logo for https://github.com/DlangScience ? Best regards, Ilya Hello, You should be able to download a svg of the new logo from the banner. Or you got this : https://en.wikipedia.org/wiki/D_%28programming_language%29#/media/File:D_Programming_Language_logo.svg I am not sure to know which is the old logo you are looking for. ps: Thanks for ndslice and mir.
Re: Could we reserve void[T] for builtin set of T ?
On Saturday, 2 April 2016 at 16:00:29 UTC, Andrei Alexandrescu wrote: Work on containers has been on hold for three reasons: 1. Paper submission to a conference (more details soon) 2. DConf organizing stuff 3. RCString work, which can proceed in the current language 4. Work on a DIP that allows safe reference counting. I am confident we'll have good results for all of the above (and containers too). Andrei Thanks for the updates (and for your work !), can't wait for DConf ! :)
Re: Could we reserve void[T] for builtin set of T ?
On Friday, 1 April 2016 at 15:45:13 UTC, Jack Stouffer wrote: On Friday, 1 April 2016 at 12:57:12 UTC, matovitch wrote: I don't know about the implementation of redblack tree in phobos, but I am willing to bet on a large performance drawback if you compare it against an optimized hash table (for example using robin-hood open addressing techniques). And I guess it is for sorted set (like a heap) with O(log N) insertion and deletion (although this may be just a theoretical worry)...Furthermore, the template constraint indicate the need of a less predicate which you may not need or want to define. https://economicmodeling.github.io/containers/containers/hashset.HashSet.html There, save everyone the trouble of implementing this in the compiler and complicating the language with special casing by just using that. Yep ! The code is even there.
Re: Could we reserve void[T] for builtin set of T ?
On Friday, 1 April 2016 at 15:39:05 UTC, Jonathan M Davis wrote: On Friday, April 01, 2016 12:57:12 matovitch via Digitalmars-d wrote: On Friday, 1 April 2016 at 12:45:23 UTC, Jonathan M Davis wrote: > As it stands, if someone wants a set with Phobos, we have > RedBlackTree in std.container. So, we actually have sets > already. But all of that will presumably be getting an > overhaul with what Andrei has been up to. I don't know about the implementation of redblack tree in phobos, but I am willing to bet on a large performance drawback if you compare it against an optimized hash table (for example using robin-hood open addressing techniques). And I guess it is for sorted set (like a heap) with O(log N) insertion and deletion (although this may be just a theoretical worry)...Furthermore, the template constraint indicate the need of a less predicate which you may not need or want to define. RedBlackTree is a red-black-tree, so it's a sorted set with whatever pros and cons come with that. Having a hash set would have different pros and cons. Ideally, we would have both, and I expect that we will eventually, but at the moment, we just have RedBlackTree, but that's more than nothing, and it's exactly what would be needed for many use cases even if a hash set were available. - Jonathan M Davis Indeed, just wanted to point that out. (I guess that's why the set was introduced before the unordered one in the c++ stl as well). I feel like containers are an old topic. Last time I asked I was told : wait for the allocators. What is the advancement on this side ? Are there any plan at writing more containers for phobos ? (I know that I am in the bad position of complaining...but if there is no obstacle...I am ready to write a draft of hashset in D, although surely not to phobos standards)
Re: Could we reserve void[T] for builtin set of T ?
On Friday, 1 April 2016 at 12:45:23 UTC, Jonathan M Davis wrote: On Friday, April 01, 2016 19:26:46 Daniel Murphy via Digitalmars-d wrote: On 1/04/2016 6:24 AM, deadalnix wrote: > Pretty much as per title. I has that in the back of my mind > for a while. Would that work ? Don't forget that builtin AAs have been an epic disaster, and this would require an appalling amount of effort to implement in the compiler types, ctfe, druntime, new traits etc. Phobos seems like a better place - and while not quite as concise, the syntax should still be pretty intuitive. Given that we already have built-in AA's, I like the idea of adding sets like this, but it wouldn't surprise me at all if it were ultimately a bad idea. Certainly, I agree that having AA's built into the language has turned into a disaster even though it's theoretically very nice to have - and it has turned out quite well for the basic use cases. It just falls apart completely once you start caring about stuff like const and immutable and anything complicated. As it stands, if someone wants a set with Phobos, we have RedBlackTree in std.container. So, we actually have sets already. But all of that will presumably be getting an overhaul with what Andrei has been up to. - Jonathan M Davis I don't know about the implementation of redblack tree in phobos, but I am willing to bet on a large performance drawback if you compare it against an optimized hash table (for example using robin-hood open addressing techniques). And I guess it is for sorted set (like a heap) with O(log N) insertion and deletion (although this may be just a theoretical worry)...Furthermore, the template constraint indicate the need of a less predicate which you may not need or want to define.
Re: Could we reserve void[T] for builtin set of T ?
On Friday, 1 April 2016 at 11:59:29 UTC, Dejan Lekic wrote: On Thursday, 31 March 2016 at 19:24:14 UTC, deadalnix wrote: Pretty much as per title. I has that in the back of my mind for a while. Would that work ? I am not sure about that... I would rather have a completely new type (`set`) for this purpose. Agreed, although it looked like a good idea at first, void[T] is kind of obscture when you compare it to std::unordered_set in C++. Although unordered_map are really practical to the point lua made it its only data structure (behind the scene of a dynamic language), when I first encountered D I thought this was sad to have add it as a build-in construct (phobos would have done fine). This thread point out one don't have a satifactory way to insert or erase keys and code a specific behavior for void[T] just remove all the interest of the similarty with AAs that we are looking for in the first place.
Re: Looking for someone that could work on 32 bits support for SDC
On Saturday, 3 October 2015 at 18:51:56 UTC, deadalnix wrote: On Saturday, 3 October 2015 at 09:44:06 UTC, ponce wrote: On Friday, 2 October 2015 at 22:35:51 UTC, BBasile wrote: Tu arrives encore à porter des boots ? au niveau des chevilles enflées ca passe encore ? Keep it civil please. He knows, that's why he wrote in french. We'll know if he is serious about it if he reopens and rebase his PR. Vu que ca parle francais, je vais pas me gener. ;) Ca sera pas pour t'insulter en echappant a la censure mais pas pour ajouter quelque chose de productif non plus. Je n'ai vraiment pas le temps de participer a un projet comme SDC mais j'ai largement le temps de te remercier pour le boulot que ca represente. J'avais regarde ta pres a la dconf 2014, l'idee de processer les noeuds de maniere asynchrone c'est juste genial (n.b. : je suis sur que tu fais gaffe aux chevilles). Keep it up ! p.s.: Il me semble que t' avais besoin d'une hashmap pour le runtime. J'ai recement code une hashtable en C++ utilisant une des meilleures technique d'open adressing (Robinhood hashing) bcp plus rapide que les hashmap de boost ou gcc (3x plus rapide en O3) tout en ayant un load factor raisonnable. Ici : https://github.com/matovitch/RobinHoodHashtable/blob/master/RobinHoodHashtable.hpp. En esperant que ca puisse t' aider.
Re: std.data.json formal review
Hi Sonke, Great to see your module moving towards phobos inclusion (I have not been following the latest progress of D sadly :() ! Just a small remark from the documentation example. Maybe it would be better to replace : value.toJSONString!true() by value.toJSONString!prettify() using a well-named enum instead of a boolean which could seem obscure I now Eigen C++ lib use a similar thing for static vs dynamic matrix. Thanks for the read. Regards, matovitch
Re: D vs nim
On Tuesday, 14 April 2015 at 10:09:15 UTC, Idan Arye wrote: On Tuesday, 14 April 2015 at 06:31:08 UTC, Jadbox wrote: btw : I think D should get rid off un-bracketed if statement, program king is not about sparing the number of lines...but that’s again a matter of taste. I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices. +1. I personally think that whenever you use unbracketed if the statement should be on the same line as the if - but that should be checked by configurable style-checkers, not by the compiler. I also don't like the idea of introducing these kinds of breaking changes when the language is supposed to be stable. Enforcing some best practices from the beginning of the language is beneficial, since I can be sure all code written in that language uses these best practices. But if such best practices are introduced when the language claims to be stable, forcing me to go all over my project to make sure it complies to it, and then forking some of the dependencies' repositories so I can do the same with them(only this time it's code that I'm unfamiliar with) - I'll seriously consider if migrating my project to a more stable language might actually be less work in the long run, considering that more breaking changes like this might be introduced in the future. Please I wouldn't like to divert this thread into a bracketed/un-bracked flame war...In fact I mostly don't care. In fact if people like it thats probably the good choice, I just like to got only one way to do it *syntax-wise*. But please talk about feature, I regret my '.btw:' section.
Re: D vs nim
Sorry if I don't make my point accurately, it's been not so long since I started learning English. I often found programming language community relates to churchs. I find D to be really present on reddit and that’s great because other people can discover that wonderful language. But blaming other language for doing the same is just plain hypocrite : if it's on top, people are interested, it's that simple. That been said I am not familiar with nim, but I am really excited about the next generation of languages like D and rust. To express my opinion about these language and note those are just *opinions*. I think D is extraordinary expressive...such a complex language too. From a metaprogramming point of view, I am mixed about string mixins, the syntax of the 'is' statement (seriously ?), do we need so many traits ? Rust opted for type classes over templates constraints and ast macros, D had no shame introducing imperative programming into the compile time word...it a choice and I kind of like even though some might think it's not really pretty. I don't like the GC much and I think I wouldn't missed the features it allowed, but that won't say I am very grateful about the recent improvements (I think it's Martin Nowak to thanks). I don't like associative arrays built-in, those are no trivial data structure and should be available in phobos. About Phobos, it's clearly a big win compare to Rust standard library...for now (only...I hope), ranges are plain awesome, algorithm is good. Modules, distinction between struct and class, ref and others storage classes well that's beyond word : awesome ! Unittests : thats political. ;) Foreach is good but why adding an index is restricted to built-in arrays and I know about ennumerate, that's not the question. Why auto ref arguments taking function should be templates (I understand there is a method duplication but that is so weird especially not coherent with auto ref *returning function) ? I have noticed something about D, sometimes some stuff might seems weird at first but often when you dig about it, you discover there is a really well thought design choice behind it. I don't now rust that much, but I have to admit it looks much prettier and a bit less expressive/powerful but again it's D I am comparing it to. The two are a great improvement on C++ I get my pittance with since four month now, that feels good. A bad think about those languages though is that they can also make you kinda hate your job sometimes. ;) Well anyway, thanks to all the people involved in the design of such heavy machineries as compilers, I hope I get more time and experience to help some day (I am more in applied maths, so I think I will try to get on this side). btw : I think D should get rid off un-bracketed if statement, programming is not about sparing the number of lines...but that’s again a matter of taste.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Sunday, 12 April 2015 at 07:17:07 UTC, Walter Bright wrote: A quick read of this suggests it is doing the Rust model of only one mutable reference at a time. Is this really viable with D? I would love to see a storage class to add the rust ownership model to D. I surely don't know if it's feasible.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Sunday, 12 April 2015 at 04:18:54 UTC, Andrei Alexandrescu wrote: On 4/11/15 5:35 AM, matovitch wrote: I am not convinced by the dip77, what about raii managed classes with costly opAssign operator (like in w0rn example) ? The goal of passing an object by reference is to avoid the copy and here you guess the parameter is ref-counted and made a (pseudo-)copy ? Then any allocating opAssign should be marked @system ? Expensive opAssign or expensive postblit? -- Andrei Well both in the example given by w0rp. I guess D as no "rule of five" but still a "rule of three" (which is in fact rule of four with the copy-and-swap idiom) about coding posblit, opAssign and destructor together ?
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Saturday, 11 April 2015 at 11:33:51 UTC, Marc Schütz wrote: On Saturday, 11 April 2015 at 09:41:07 UTC, Walter Bright wrote: On 4/11/2015 2:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: It's not acceptable that it happens behind the user's back. Costly operations must be explicit. Don't know of a better solution. How about this? http://wiki.dlang.org/User:Schuetzm/scope3#.40safe-ty_violations_with_borrowing Btw, I also made other changes: No implied scope for @safe functions, no overloading on scope (instead postblit and destructor are skipped), and added a terminology section (rather important!). Just passing, a bit off topic and clearly not familiar enough with the discussed subject but in case you missed it the last rust blog post is an nice and motivated introduction to their ownership system : http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html I need to read about Marc's scope proposal...I am not convinced by the dip77, what about raii managed classes with costly opAssign operator (like in w0rn example) ? The goal of passing an object by reference is to avoid the copy and here you guess the parameter is ref-counted and made a (pseudo-)copy ? Then any allocating opAssign should be marked @system ?
Re: Template constraints
Sorry for the mistakes in the above message (and in this one). I didnt gave earlier my personnal opinion on the matter but essentially if I like the syntax of type classes very much, you can do much more with templates constraint and D meta programming abilities...But you still have to fix some kind of pragmatic limit in the compile time introspection I think...
Re: Template constraints
On Sunday, 15 March 2015 at 10:40:17 UTC, w0rp wrote:
On Sunday, 15 March 2015 at 08:29:01 UTC, bearophile wrote:
Observe:
https://github.com/D-Programming-Language/phobos/pull/3054
Is this change the partial proof of another failure of a part
of D language design? What's the point of template
constraints? Aren't C++ Concepts better? Or to rephrase that
in a less trollish way, can D be enhanced to add user-defined
error messages to template constraints, and is such
enhancement a good idea?
Bye,
bearophile
It's funny you mentioned concepts, because I was just watching
Bjarne's CppCon 2014 keynote again and I took away two things
from it.
1. For the overwhelming majority of things Bjarne wants from
C++ mentioned in that keynote, D has done all of them, and
better...
2. ...except for concepts.
I believe D does the template error message thing a *whole lot*
better than C++. That's all because of template constraints,
static if, and static assert, and I believe those are down to
Andrei's influence. (Though others likely deserve credit for
their design, implementation, and maintenance. As always you'll
probably have to nod to Kenji who works like crazy.)
I've been wondering what we can do to make specifying
constraints for something like ranges a little easier to write,
with obviously some underlying complexities which will be hard
to implement. This doesn't address your concern about error
messages for constraints really, but what I've thought of is
roughly this.
Say you write 'copy' currently. You'll do something like this.
void copy(InputRange, OutputRange)(InputRange inputRange,
OutputRange)
if (isInputRange!InputRange && isOutputRange!OutputRange) {
/* Some implementation of copying. */
}
Maybe you'll use less verbose names and all kinds of things,
but essentially that is what you're after. I've been wondering
if it's possible to use compiler magic to make this possible.
// These names conflict with our interfaces in std.range,
whatever, imagine
// some other name place of them if you like.
template InputRange(T) {
enum InputRange = isInputRange!T;
}
// The newer syntax makes the above easier...
enum OutputRange(T) = isOutputRange!T;
// Now this works with magic...
void copy()(InputRange inputRange, OutputRange outputRange) {
/* Some implementation of copying. */
}
If you write this now, the compiler will print an error saying,
"Hey, you just attempted to use this template which takes one
argument as a type in this paramter list right here." My idea
is to take that information and instead of returning an error,
just go, "Oh, I'll just add another template parameter onto the
end of your template parameter list here, replace the thing
which really should be a type here with T from the parameter
list, use deduction to insert the type for T and then use it,
then use the template you had originally as a test on the type
T yielding our boolean expression." I left the extra parens in
there for 'copy' as I reckon they'll probably be a requirement
anyway, and then you can't make accidental templates.
You might have to read what I wrote four times to make sense of
it, but that's my crazy idea others can destroy. I'm more of a
wild idea guy than a formal specification guy.
I am not sure of what you want to do but that looks like
"meta-type" like :
void copy(InputRange IRage, OutputRange ORange) (IRange src,
Orange dest) {
/* Some implementation of copying. */
}
Hashkell has something like that for a long times (early 90s I
think) wich is call type classes. Essentially, it checks that the
type implement a certain interface (operators included). You
could do the same in c++ with boost (now maybe std)::is_base_of I
think.
Re: A Refcounted Array Type
On Tuesday, 24 February 2015 at 10:16:00 UTC, Ulrich Küttler
wrote:
On Tuesday, 24 February 2015 at 10:13:36 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 10:11:02 UTC, Namespace wrote:
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
That's why:
this(this)
{
if (count)
++*count;
}
Hmm, I don't see why that's why... :(
The counter is shared amount all "copies" of the array.
Ah yes, what an idiot ! Thanks !
Re: A Refcounted Array Type
On Tuesday, 24 February 2015 at 10:11:02 UTC, Namespace wrote:
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 09:44:13 UTC, Walter Bright
wrote:
On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d
wrote:
The issue is that delete is considered @safe by the compiler,
I thought more people would be interested in how to do a
memory safe reference counted container.
This is really interesting ! Thought as a beginner, I am
wondering why the counter need to be a pointer ?
That's why:
this(this)
{
if (count)
++*count;
}
Hmm, I don't see why that's why... :(
Re: A Refcounted Array Type
On Tuesday, 24 February 2015 at 09:44:13 UTC, Walter Bright wrote: On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d wrote: The issue is that delete is considered @safe by the compiler, I thought more people would be interested in how to do a memory safe reference counted container. This is really interesting ! Thought as a beginner, I am wondering why the counter need to be a pointer ?
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 19:57:49 UTC, matovitch wrote: On Thursday, 29 January 2015 at 19:02:22 UTC, Jonathan Marler wrote: On Thursday, 29 January 2015 at 18:38:33 UTC, deadalnix wrote: Does it really matter ? Please put your first post in there and be done with it. These proposal are not gonna happen anyway (the ROI is simply not there). Post is up. I agree with you that the ROI is not there, however, if someone doesn't understand why then it's good to help them understand. It produces better developers and helps bring the D community together to have a common understanding. In an ideal world with infinite time we could answer everyone's questions with great detail and walk them through all their concerns and ideas. However, since time is a finite resource, I think having a wiki we can point people to is a great compromise. I saw this suggestion in the thread by multiple people and I think it would help to address it in the wiki. This attitude of thinking that addressing people's concerns doesn't matter is a bit harsh and hurts the language. I've seen that many upper developers share this attitude and it pushes people away from wanting to contribute. I like *your* attitude ;) I am reading http://dlang.org/attribute.html and realizing how subtle this can be...indeed, the distinction of qualifier vs attributes is fuzzy in my head even, qualifiers are defined to be attributes in the spec...Attribute is a node of the grammar in fact so the def is really accurate but I think with more thinking one could think of something more consistent than it has @ because this is a keyword because the next question will be then why isn't this a keyword because that is a keyword...etc. Write the FAQ a wiki can always be improved. You wrote it ! This looks great ! :)
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 19:02:22 UTC, Jonathan Marler wrote: On Thursday, 29 January 2015 at 18:38:33 UTC, deadalnix wrote: Does it really matter ? Please put your first post in there and be done with it. These proposal are not gonna happen anyway (the ROI is simply not there). Post is up. I agree with you that the ROI is not there, however, if someone doesn't understand why then it's good to help them understand. It produces better developers and helps bring the D community together to have a common understanding. In an ideal world with infinite time we could answer everyone's questions with great detail and walk them through all their concerns and ideas. However, since time is a finite resource, I think having a wiki we can point people to is a great compromise. I saw this suggestion in the thread by multiple people and I think it would help to address it in the wiki. This attitude of thinking that addressing people's concerns doesn't matter is a bit harsh and hurts the language. I've seen that many upper developers share this attitude and it pushes people away from wanting to contribute. I like *your* attitude ;) I am reading http://dlang.org/attribute.html and realizing how subtle this can be...indeed, the distinction of qualifier vs attributes is fuzzy in my head even, qualifiers are defined to be attributes in the spec...Attribute is a node of the grammar in fact so the def is really accurate but I think with more thinking one could think of something more consistent than it has @ because this is a keyword because the next question will be then why isn't this a keyword because that is a keyword...etc. Write the FAQ a wiki can always be improved.
Re: FAQ for newbies who see pure @safe nothrow @nogc
About the lists Qualifiers : const (can be an method attribute), immutable (can be an method attribute), inout, shared, (scope ?) Attributes : const (can be a type qualifier), immutable (can be a type qualifier), final (even so I don't understand why private final is so special), pure, @nothrow, @property, @nogc,... Neither qualifier nor attributes : abstract, override,... and many others Why "override" is not a method attribute...because if you remove it you've change the "semantic" of the code..."final" doesn't change anything if you remove it. To me, a function/method attribute enforce a behaviour on the function but you should be able to remove it without changing the "semantic".
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 16:13:59 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 16:02:44 UTC, matovitch wrote:
On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
Yes, if @ttributes are better because you can create
identifier with the same name why aren't they used
everywhere ? By the way, the denomination makes sense too :
function attibutes are either built-in or user defined
attributes. But const can be a qualifier or a
function/method attribute that is two very different
things...maybe not beeing able to use const as a function
attribute but @const would make more sense ?
The purpose of this thread wasn't to re-discuss what was
already discussed. The answer to your idea can be found in
the other thread
http://forum.dlang.org/post/rtwbtxigfeupvykpb...@forum.dlang.org.
It's gonna be a long read so I'll summarize what I believe is
the correct answer.
The problem we are trying to solve is that the function
attributes are inconsistent. Some use @ like "@safe" and
"@nogc" and some don't like "pure" and "nothrow".
So one idea is to require an '@' symbol in front of all of
them for the sake of consistency. The problem with this idea
is that you've now introduced inconsistency somewhere else.
Every keyword that you put an '@' symbol in front of, will be
used somewhere else without an '@' symbol. Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of
these types of inconsistencies. In addition, you've made the
rule of when to use the '@' symbol more complex. Before it
was, "Use '@' if it is not a keyword". Now it's, "Use '@' if
it is not a keyword except when it's a function attribute".
This definition will likely be made worse since people will
want to solve the newly introduced inconsistencies. So the
new definition will become, "Use '@' if it is a keyword
except if it's a function attribute or a class specifier".
By the time you solve every inconsistency you'll have made
every usage of every keyword use the '@' symbol. Then the
rule will be "Always use the '@' symbol".
This will definitely be included on the FAQ :) I'll reword
it and modify it but I agree that people will want an
explanation for this.
One can argue that it's hard to remember what is a keyword
(especially in D where there are many) and easier to
distinguish beetween qualifiers and attributes. But I
understand legacy code is an issue and I agree that the FAQ
should just state the facts.
This doesn't really have to do with Legacy code. You can
always support both ways for a time and deprecate the old way.
It appears my answer did not address your idea well enough.
I'll have to put together a better explanation. In the mean
time, could you help me by giving me the gritty details of your
idea. I know others will also want an explanation for this so
I'd like to include one in the FAQ so as to prevent us from
explaining the same thing over and over. You idea was to put
'@' on words if they are attributes and to omit them on
qualifiers. Could you list what words are qualifiers and what
words are attributes? I don't think this idea would work but
hey, maybe you'll prove me wrong, I'll admit I haven't gone
through the details of what problems this idea would create.
Sorry this may be my fault. I think there were only 4 qualifier
in D : const, immutable, share and inout (I am not aware of this
new "scope" thing). pure is a function attribute and a keyword,
this is inconsistant with other built-in attributes with @ in
front of them like @property or @nogc. I think (and my opinion
doesn't worth much as I am not experienced as a programmer and I
didnt used D very much) that it would be more consistant if we
hadn't this keyword and be forced to use @pure instead. (const
can be a method annotation/attribute too, so should be @const
keeping const as a variable/parameter qualifier).
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
Yes, if @ttributes are better because you can create
identifier with the same name why aren't they used everywhere
? By the way, the denomination makes sense too : function
attibutes are either built-in or user defined attributes. But
const can be a qualifier or a function/method attribute that
is two very different things...maybe not beeing able to use
const as a function attribute but @const would make more sense
?
The purpose of this thread wasn't to re-discuss what was
already discussed. The answer to your idea can be found in the
other thread
http://forum.dlang.org/post/rtwbtxigfeupvykpb...@forum.dlang.org.
It's gonna be a long read so I'll summarize what I believe is
the correct answer.
The problem we are trying to solve is that the function
attributes are inconsistent. Some use @ like "@safe" and
"@nogc" and some don't like "pure" and "nothrow".
So one idea is to require an '@' symbol in front of all of them
for the sake of consistency. The problem with this idea is
that you've now introduced inconsistency somewhere else. Every
keyword that you put an '@' symbol in front of, will be used
somewhere else without an '@' symbol. Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of these
types of inconsistencies. In addition, you've made the rule of
when to use the '@' symbol more complex. Before it was, "Use
'@' if it is not a keyword". Now it's, "Use '@' if it is not a
keyword except when it's a function attribute". This
definition will likely be made worse since people will want to
solve the newly introduced inconsistencies. So the new
definition will become, "Use '@' if it is a keyword except if
it's a function attribute or a class specifier". By the time
you solve every inconsistency you'll have made every usage of
every keyword use the '@' symbol. Then the rule will be
"Always use the '@' symbol".
This will definitely be included on the FAQ :) I'll reword it
and modify it but I agree that people will want an explanation
for this.
One can argue that it's hard to remember what is a keyword
(especially in D where there are many) and easier to distinguish
beetween qualifiers and attributes. But I understand legacy code
is an issue and I agree that the FAQ should just state the facts.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 15:10:12 UTC, Jonathan Marler wrote: On Thursday, 29 January 2015 at 10:43:37 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:38:46 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ? "In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without @, then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without @, then we'll be forced to change pretty much every D program in existence." JM Davis Ok ! I'm not sure I understand your question. Why don't we make all the function attributes attributes? Is this what you mean? "Why don't we require an '@' symbol before all function attributes?" Yes, if @ttributes are better because you can create identifier with the same name why aren't they used everywhere ? By the way, the denomination makes sense too : function attibutes are either built-in or user defined attributes. But const can be a qualifier or a function/method attribute that is two very different things...maybe not beeing able to use const as a function attribute but @const would make more sense ?
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 10:38:46 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ? "In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without @, then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without @, then we'll be forced to change pretty much every D program in existence." JM Davis Ok !
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ?
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes?
Re: What is the D plan's to become a used language?
On Sunday, 21 December 2014 at 11:18:43 UTC, Joakim wrote: Native efficiency combined with expressiveness and ease of use, as the front page says. That's too general-purpose to just go build some specialized app like docker, but in the long run may lead to much bigger wins. I think so too, D aims at a broader goal than most of the new languages out there. I find the people in here quite grumpy these days. D is already a great usable and enjoyable language. I agree that some features should be removed and other extended for closure. But it's nothing that can't be achived in a few years.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Tuesday, 18 November 2014 at 12:33:52 UTC, FrankLike wrote: If you migrate your projct from x86 to x64,you will find the length is error,you must modify it ,such as: int i= (something).length to size_t i = (something).length but now ,'int' is enough for use,not huge and not small,only enough. 'int' is easy to write,and most people are used to it. Most importantly easier to migrate code,if 'length''s return value type is 'int'. Thank you all. I'm using size_t and std::size_t in C/C++...but sure I am a bit weird/extremist.
Re: Integral literals with Exp?
On Saturday, 13 September 2014 at 07:23:39 UTC, bearophile wrote:
Is it a good idea to accept code like this, to shorten some
constants?
void main() {
int x = 1e6;
}
Bye,
bearophile
Well, I guess it wouldn't help the lexer. To be consistent :
int x = 1.73e2;
should be allowed but not
int y = 1.73e1;
Not a good idea IMHO.
Re: zero-ing is not enough
On Tuesday, 9 September 2014 at 07:09:52 UTC, bearophile wrote: John Colvin: http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html D could incorporate something like this, no? See: https://d.puremagic.com/issues/show_bug.cgi?id=10661 Walter seems OK with adding something like that to the D intrinsics. Bye, bearophile I am by no mean a security expert and this article scared me *a lot*. Are there any truly secure TLS implementation ? There may be room for an @crypto attribute where the stack, the registers or the dynamically allocated memory would be zeroed out in the end ? But as stated in the comments, it's probably more of an OS job since a program may always crash.
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 13:00:19 UTC, Sönke Ludwig wrote:
Am 22.08.2014 14:47, schrieb matovitch:
Ok. I think I remember there was a stdx.d.lexer's Json parser
provided
as sample.
I see, so you just have to write your own number/string parsing
routines:
https://github.com/Hackerpilot/lexer-demo/blob/master/jsonlexer.d
It's kind of "low level" indeed...I don't know what kind of back
magic are doing all these template mixins but the code looks
quite clean.
Confusing :
// Therefore, this always returns false.
bool isSeparating(size_t offset) pure nothrow @safe
{
return true;
}
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 12:39:08 UTC, Sönke Ludwig wrote: Am 22.08.2014 14:17, schrieb matovitch: Very nice ! I had started (and dropped) a json module based on Algebraic too. So without opDispatch you plan to use a syntax like jPerson["age"] = 10 ? You didn't use stdx.d.lexer. Any reason why ? (I am asking even if I never used this module.(never coded much in D in fact)) Exactly, that's the syntax you'd use for JSONValue. But my favorite way to work with most JSON data is actually to directly read the JSON string into a D struct using a serialization framework and then access the struct in a strongly typed way. This has both, less syntactic and less runtime overhead, and also greatly reduces the chance for field name/type related bugs. Completely agree, I am waiting for a serializer too. I would love to see something like cap'n proto in D. The module is written against current Phobos, which is why stdx.d.lexer wasn't really an option. I'm also unsure if std.lexer would be able to handle the parsing required for JSON numbers and strings. But it would certainly be nice already if at least the token structure could be reused. However, it should also be possible to find a painless migration path later, when std.lexer is actually part of Phobos. Ok. I think I remember there was a stdx.d.lexer's Json parser provided as sample.
Re: RFC: std.json sucessor
Very nice ! I had started (and dropped) a json module based on Algebraic too. So without opDispatch you plan to use a syntax like jPerson["age"] = 10 ? You didn't use stdx.d.lexer. Any reason why ? (I am asking even if I never used this module.(never coded much in D in fact))
Re: DSLs for high performance computing
On Tuesday, 24 June 2014 at 21:01:34 UTC, Guillaume Chatelet wrote: On Wednesday, 18 June 2014 at 19:00:26 UTC, Andrei Alexandrescu wrote: A coworker brought this list to my attention: https://xstackwiki.modelado.org/DSL%27s The work on such DSLs (reminiscent of Don's work on optimizing matrix operations years ago) seems be on the rise. I didn't know most of them. I encourage everybody interested in Image/Signal Processing to have a look at Halide Talk https://www.youtube.com/watch?v=3uiEyEKji0M papers http://halide-lang.org/ I don't know if it's already available in the source code but they mention the scheduling part can now be optimized through genetic algorithms : the code will autotune to use the best of your hardware, exploring the space of precomputing (stencil buffer), inlining, multithreading, vectorization, unrolling, sliding window ... Thanks for sharing Andrei :) Halide looks just *mind-blowing* though I couldn't find any project using it on github (other than toy-examples). I couldn't find anything either in the doc about the automatic scheduling they mention in their paper. I am wondering if it is possible to perform linalg operations, it seems rather convolution-oriented. Anyway, it would be awesome to have a D front-end (not that I have the time to code it, I usually just talk ;)). Else : Preferably to DSLs though, I am more waiting something as basic as containers based on std.allocator or a standard multi-dimensional array (with range behaviour based on a permutation of the dimensions and allow borrowed slices of any subspace). Well in fact I am not waiting since I do not have the time to code in D but if I had the time this is what I would be waiting/working for. Keep it up !
Re: Stable topN?
On Tuesday, 24 June 2014 at 11:50:37 UTC, Xinok wrote: On Tuesday, 24 June 2014 at 04:40:48 UTC, Peter Alexander wrote: On Monday, 23 June 2014 at 22:47:20 UTC, Xinok wrote: What do you all think? Do you agree with my definition of stable topN? Do you know of a better algorithm/approach for implementing this function? I agree with your definition, and can't think of a better algorithm, but wouldn't a stable sort have the same effect as your algorithm? Both are O(n lg(n)) time and O(n) space. A stable sort would lose the original ordering of the elements though. Furthermore, the entire point of the topN function is to be faster than simply sorting the range. Yes you can't use stable sort. However you can use a priority queue, which would made the algorithm worst case O(M log N) in time and O(N) in space. (M is the number of elements in the original array and N the number of top elements)
Re: DIP63 : operator overloading for raw templates
Well I realized I was a bit off-topic there since it is not about ctfe operators but raw template operators. I'm out.
Re: DIP63 : operator overloading for raw templates
On Monday, 16 June 2014 at 08:56:24 UTC, Marc Schütz wrote:
On Sunday, 15 June 2014 at 18:32:31 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP63
This is solution for a problem I am currently having with
implementing http://wiki.dlang.org/DIP54 (afair it was also
mentioned by Timon Gehr during old discussion of that DIP)
New proposed semantics ( to catch your attention and get to
read the link ;) ):
template Pack(T...)
{
alias expand = T;
alias opIndex(size_t index) = T[index];
alias opSlice(size_t lower, size_t upper) =
Pack!(T[lower..upper]);
alias opDollar = T.length;
}
// no ambiguity as Pack!(int, int) is not a valid type
// is(element == int)
alias element = Pack!(int, int)[1];
I guess there's no way around it, but it seems inconsistent
that the operators are defined as templated aliases instead of
functions as anywhere else. Could you add a paragraph to the
DIP which points this out and give a short justification?
+1
And why these operators only ?
struct StaticVariant
{
alias opAssign(T t) = (immutable T x = t; alias x this;)
}
struct Json
{
immutable (StaticVariant[string]);
alias opDispatch(string s, T t) = (data[s] ~= t);
alias opDispatch(string s) = data[s];
}
void main()
{
Json john;
john.size = 1.78;
john.name = "John";
float johnSize = john.size;
string johnName = john.name;
}
Ok I am a dreaming D beginner. In this case multiple alias this
would be better. Also, I don't understand why we can't append
immutable array thanks to CTFE too. D is awesome in lots of ways
but it's quite frustrating too because it frees your imagination.
Where do we set the limit in terms of meta-meta-stuff ?
Re: A crazy idea for accurately tracking source position
You are doing it all wrong. The easiest way to compute the col position is the following : col_pos = 0; if (non_tab_character_encounter) col_pos++; else col_pos += tab_length - col_pos % tab_length; That's it.
