Re: http://wiki.dlang.org/DIP25
On 12/29/14, Andrei Alexandrescu via Digitalmars-d wrote: > We're in the "cooperative" stage of D, and we need to move toward the > "established organization" stage. Unrelated to this grander idea I really liked the recent Rust blog post: http://discuss.rust-lang.org/t/a-tale-of-twos-complement/1062 We could consider writing these styles of posts for major changes (like DIP25). We already have the changelog that documents everything /after/ a release, but having a page where we announce upcoming changes for the general population to read would be nice. Once we agree on all aspects on DIP25, perhaps we could write a page about it and put it up on dlang.org/news.html or somewhere. What do you think?
Re: Lost a new commercial user this week :(
On 29 December 2014 at 03:52, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/28/14 6:43 PM, Manu via Digitalmars-d wrote: >> >> On 27 December 2014 at 02:21, Andrei Alexandrescu via Digitalmars-d >> wrote: >>> >>> On 12/25/14 5:18 PM, Mike Parker wrote: On 12/26/2014 9:48 AM, Manu via Digitalmars-d wrote: > > Ironically, the string and algorithm functions are probably the worst > offenders, but coincidentally, there is a high chance that these are > the first functions anyone will ever reach for, so they present a > terrible first impression. > +1 When I first made the move from D1 to D2, this caused me no end of frustration. The docs were quite unhelpful in this regard. It irked me enough that I wrote a rant about it on my old blog. It doesn't bother me anymore, so I haven't thought about it in years. This post brings it back. >>> >>> >>> >>> I thought the std.algorithm stuff is decently documented. What would be >>> the >>> major pain points? -- Andrei >>> >> >> The first line of text respectively: >> >> C#: >>public static void Sort(T[] array) >> >> D: >>SortedRange!(Range, less) sort(alias less = "a < b", SwapStrategy ss >> = SwapStrategy.unstable, Range)(Range r) if ((ss == >> SwapStrategy.unstable && (hasSwappableElements!Range || >> hasAssignableElements!Range) || ss != SwapStrategy.unstable && >> hasAssignableElements!Range) && isRandomAccessRange!Range && >> hasSlicing!Range && hasLength!Range); >> >> >> I'm sure you can see the problem... > > > Thanks, following your feedback I have recently submitted an enhancement > request. Just for the sake of humblebragging, C#'s sort works only on arrays > whereas D's sort (a) returns a statically-informed sorted range with > specific primitives, (b) is configurable to use a custom predicate, (c) > allows stability selection, (d) works for any range satisfying certain > requirements. Yay...? :o) > > Andrei > The new layout solves half the problem in that it hides the template constraints. http://dlang.org/library/std/algorithm/sort.html Shouldn't our focus also be to get the new layout out of "preview" mode and do our standardization of documentation from there? By the way, I would also nick pick on top of Manu's suggestion that the short description for sort() is just "Sorts". I'm sure this can be expanded to more than one word and less than twelve. Iain.
Re: Lost a new commercial user this week :(
On Saturday, 27 December 2014 at 08:32:29 UTC, Mike Parker wrote: It would also be nice to anticipate that people looking to operate on strings would look in std.string for things that are elsewhere. Once upon a time, the std.string docs actually did have a table of links for functions that had been moved to other pages. That was convenient and shouldn't have been removed, IMO. Finding a string in another comes to mind. Is it "countUntil"? I'm still unsure if there is a min/max function I could use for builtin types in Phobos. I've found myself several times searching the following in Rosetta Code, and wished there was a site for common idioms.
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 09:35:25 UTC, Iain Buclaw via Digitalmars-d wrote: The new layout solves half the problem in that it hides the template constraints. http://dlang.org/library/std/algorithm/sort.html Shouldn't our focus also be to get the new layout out of "preview" mode and do our standardization of documentation from there? Iain. Couldn't agree more. It also scales way better than DDOC at the module level (http://dlang.org/library/std/datetime.html VS http://dlang.org/phobos/std_datetime.html). Additionally, it could allow us to have multiple version of the doc supported, which is quite useful when migrating stuff / working with an older release. What is missing / required to definitely switch ?
Re: http://wiki.dlang.org/DIP25
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote: There is a rub though. Not only you're telling what we'd need to do to be more successful, you're also telling us how to do it. Please don't. We are not adding type qualifiers to D if we can avoid it, and generally we want to achieve what we need to achieve with minimum aggravation. Instead please focus on what you're trying to accomplish, not on whether an artifact is a type qualifier or a storage class. Thanks. Andrei But (one of) his point(s) is that the choice between type qualifier and storage class directly impacts his work. Why shouldn't a user express such a point?
Re: Worst Phobos documentation evar!
On 2014-12-29 06:39, Walter Bright wrote: Having used both Ddoc and Markdown, I seriously disagree with this. Take a look at the markdown source for DIP69. It's horrific. Do you mean on the wiki? The wiki doesn't use Markdown. At least not anyone I've seen. -- /Jacob Carlborg
Re: Documenting parameters [was: Re: Worst Phobos documentation evar!]
On Monday, 29 December 2014 at 00:50:10 UTC, Walter Bright wrote: It's already possible. Change the macro definitions in the std.ddoc file. Sure. But I did think it might be a good idea to discuss things here first before jumping into changing anything. After all, you might have good reasons for the current defaults being as they are.
Re: Worst Phobos documentation evar!
On 2014-12-29 01:45, Walter Bright wrote: I don't want to use Markdown. The D wiki uses it, and once you step outside of the trivial, you have to insert html that is crippled in various erratic ways. Any non-trivial documentation winds up being one ugly mo-fo. I does not use Markdown. $(XREF string, join) #string.join Sorry, I don't see a big issue. Trouble with the latter, of course, is what happens when you want '#' to appear in the display? Then you need some sort of escape mechanism. And then special syntax for every markup element. Bleh, I don't think there's a net improvement. XREF only work for one level of package. -- /Jacob Carlborg
Re: DConf 2015?
On Tuesday, 23 December 2014 at 00:25:33 UTC, Walter Bright wrote: On 12/22/2014 12:59 PM, Iain Buclaw via Digitalmars-d wrote: On 22 December 2014 at 20:52, Walter Bright via Digitalmars-d wrote: On 12/22/2014 9:40 AM, Adam D. Ruppe wrote: By this time last year, dconf 2014 preparations were already under way but I haven't heard anything this year. Is another one planned? Yes. Still working on getting confirmation of the date. You mean to say that it's moving from it's usual time slot next year? (Weekend before spring bank holiday) Looks like it'll be May 27-29. Hi I've recently started programming in D and I have set up a London meetup group - http://www.meetup.com/London-D-Programmers/ I'm interested in coming to the next D conference. Please let me know if there is anything I can do to help out. I've been working on IDE support for intellij here: https://github.com/kingsleyh/DLanguage which I thought might be an interesting topic for a brief presentation. Although I guess it depends on the audience at these conferences. Will the next one be in the same place? I'm based in London - I guess it's not going to be in London?
module win32.winioctl :IOCTL_STORAGE_EJECT_MEDIA' Value is Error
Now,I use the win32.winioctl.d file,find :IOCTL_STORAGE_EJECT_MEDIA ' Value is 0x0202,if you use it ,will get the error value 50.(by GetLastError()). It should be 0x2d4808.If you use it ,it works ok. Why have this kind of mistake? Frank
Re: module win32.winioctl :IOCTL_STORAGE_EJECT_MEDIA' Value is Error
Am 29.12.2014 um 13:00 schrieb FrankLike: Now,I use the win32.winioctl.d file,find :IOCTL_STORAGE_EJECT_MEDIA ' Value is 0x0202,if you use it ,will get the error value 50.(by GetLastError()). It should be 0x2d4808.If you use it ,it works ok. Why have this kind of mistake? Frank maybe just a bug but https://github.com/Diggsey/druntime-win32/blob/master/winioctl.d seems to be correctly defined IOCTL_STORAGE_EJECT_MEDIA = CTL_CODE_T!(IOCTL_STORAGE_BASE, 0x0202, METHOD_BUFFERED, FILE_READ_ACCESS),
Re: Documenting parameters [was: Re: Worst Phobos documentation evar!]
On 29/12/14 01:48, Walter Bright via Digitalmars-d wrote: Ddoc does not generate html markup. It generates macro calls, and the macro definitions default to expanding to html. You can override them to produce other effects. Yes, understood, but I'm talking about the defaults here -- it would be nice if they were set in such a way as to offer better interaction with CSS+JavaScript. It's fine if you want to say "patches, please", but there might be practical reasons why the defaults are as they are, so I wanted to sound out the idea first.
const Propagation
Hi all,
I've got a little problem regarding const. In fact, my problem
originates from C++ where I've tried to implement a visitor that
deals with both const and non-const objects. As this did not work
out, I checked whether it would work in D. Unfortunately, I could
not figure out how. Maybe someone can help.
Basically, I would like to propagate constness to a lambda
function. Here's the example code:
import std.stdio;
class Hugo {
public int x = 42;
void blah(void function(Hugo h) f) {
f(this);
}
}
void main() {
Hugo hugo = new Hugo();
void function(Hugo h) f = function(Hugo h) {
h.x = 99;
};
hugo.blah(f);
const Hugo inge = hugo;
void function(Hugo h) g = function(Hugo h) {
writeln("foobar");
};
inge.blah(g);
}
This does not compile. The D compiler complains that I must not
call a mutable method on a const object (inge). However, if I
make the method const, I have to also make the parameter of the
lambda const which results in the compiler rejecting the call
"hugo.blah(f)" since this lambda actually modifies the object.
I hope you get what I want. I want to be able to call blah() on a
const instance of Hugo with a lambda that does not modify its
argument and otherwise call blah() with any function, even one
that modifies the object. Is that possible?
Thank you very much!
Re: const Propagation
You need to overload on const, and also pass in a correctly typed
function as the argument (you can't call a function with a
mutable parameter with a const object.
import std.stdio;
class Hugo {
public int x = 42;
void blah(void function(Hugo h) f) {
f(this);
}
// OVERLOAD
void blah(void function(const Hugo h) f) const {
f(this);
}
}
void main() {
Hugo hugo = new Hugo();
void function(Hugo h) f = function(Hugo h) {
h.x = 99;
};
hugo.blah(f);
const Hugo inge = hugo;
// CHANGE TYPE HERE
void function(const Hugo h) g = function(const Hugo h) {
writeln("foobar");
};
inge.blah(g);
}
Re: const Propagation
Thank you for your answer. This kind of thing also works for C++, but that would mean that I would implement the whole visitor twice - one const and one non-const version. Is that really the only way? Can't I tell the D compiler that "the argument of that lambda shares the const-ness of the current object"? D offers "inout"; this actually aims into the right directing, but I guess it does not help here. Is there any "static if"-something construct to check the const-ness of an object?
Re: const Propagation
So I hope you understand; I've got no problem with changing the type of the function g as you supposed. The bad thing is the additional overload that results in duplicated code.
Re: http://wiki.dlang.org/DIP25
On 12/28/14 4:33 PM, Walter Bright wrote: On 12/28/2014 12:04 PM, Peter Alexander wrote: On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote: Very little breakage I can think of. Ranges usually don't own their payload. I'm thinking more about higher order ranges, e.g. take, filter, cycle, retro; over a mutable range with ref front. Even if the underlying range (e.g. an array) has the inout, the higher order range will need the inout as well, so that it is propagated, no? inout is not transitive, so a ref on the container doesn't apply to a ref on the contents if there's another level of indirection in there. I'm not sure what you mean by this, but inout as a type modifier is definitely transitive. -Steve
Re: http://wiki.dlang.org/DIP25
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.
Please comment: http://wiki.dlang.org/DIP25
ref int hun() inout { return b; }
This doesn't make sense. inout cannot cast to mutable.
Other than that, there is an issue with taking ref mutable parameters.
For example, you cannot implement an increment function:
ref int increment(ref int x) { return ++x;}
marking x as inout makes it effectively const during the body of the
function, so such a function would be banned. I'm sure there are some of
these in some code somewhere, I wouldn't be surprised if phobos had some.
I like the idea of inferring lifetime based on inout, and I think that
connection is sound. But I don't like the idea of *requiring* inout to
qualify ref returns of parameters. It's too restrictive.
-Steve
Re: Inferred Type for Explicit Cast
On Wednesday, 24 December 2014 at 03:11:40 UTC, Andrei Alexandrescu wrote: On 12/20/14 6:47 PM, Steven Schveighoffer wrote: On 12/20/14 5:20 AM, Dicebot wrote: I'd like to have a cast where you must define both "from" and "to" types precisely. I was actually thinking the same thing. This would be almost future-proof (any changes to either side would result in failed compilation). -Steve Specifying two types instead of one in a "to" call should achieve that. -- Andrei This is different. `to` is about "smart" conversion (and potentially costly with allocations flying around) - we are speaking about same basic dumb cast here, just more controlled.
Re: What's missing to make D2 feature complete?
On Thursday, 25 December 2014 at 10:06:35 UTC, Martin Nowak wrote: On Sunday, 21 December 2014 at 12:48:42 UTC, Dicebot wrote: On Sunday, 21 December 2014 at 12:26:04 UTC, Jacob Carlborg wrote: On 2014-12-21 10:46, Dicebot wrote: Stuff that immediately comes to my mind: - some way to define implicit conversion from literals (done at CT) Any ideas on that? It's an outstanding problem for the library AA work. No, sadly no right now - it is not a pressing issue for things I need right now so I avoid investing too much thinking into finding sound solution, sorry :(
Re: const Propagation
On Monday, 29 December 2014 at 13:22:41 UTC, Julian Kranz wrote:
So I hope you understand; I've got no problem with changing the
type of the function g as you supposed. The bad thing is the
additional overload that results in duplicated code.
So you can write something like this:
import std.stdio;
class Hugo {
public int x = 42;
void blah(this T)(void function(T h) f)
{
f(this);
}
}
void main() {
Hugo hugo = new Hugo();
void function(Hugo h) f = function(Hugo h) {
h.x = 99;
};
hugo.blah(f);
const Hugo inge = hugo;
void function(const Hugo h) g = function(const Hugo h) {
writeln("foobar");
};
inge.blah(g);
}
Re: const Propagation
On 12/29/14 8:20 AM, Julian Kranz wrote:
Thank you for your answer. This kind of thing also works for C++, but
that would mean that I would implement the whole visitor twice - one
const and one non-const version. Is that really the only way? Can't I
tell the D compiler that "the argument of that lambda shares the
const-ness of the current object"?
D offers "inout"; this actually aims into the right directing, but I
guess it does not help here.
inout is not smart enough to know what the inout on a lambda means. It
also can be confusing to understand that during the entire execution of
an inout function, the inout parameters are treated as const. This would
preclude using inout to do what you want.
Is there any "static if"-something construct to check the const-ness of
an object?
Static-if applies to generic coding, i.e. templates. A template function
may work, but I don't think you even need static if:
class Hugo { ... }
void blah(T)(T obj, void function(T t) f) if(T : Hugo) { f(obj);}
This should work with all iterations of Hugo, and is callable via UFCS:
hugo.blah(f); // should work
I don't know if a template member function would be possible, as I'm
pretty sure templates do not infer const.
(admittedly, I have not tested any of this)
-Steve
Re: const Propagation
On 12/29/14 9:18 AM, Steven Schveighoffer wrote:
Static-if applies to generic coding, i.e. templates. A template function
may work, but I don't think you even need static if:
class Hugo { ... }
void blah(T)(T obj, void function(T t) f) if(T : Hugo) { f(obj);}
um...
blah(T : Hugo)(T obj, void function(T t) f) { f(obj); }
Maybe this will work better, but still untested :) You may need T :
const(Hugo).
-Steve
Re: Lost a new commercial user this week :(
On Friday, 26 December 2014 at 01:11:42 UTC, Manu via Digitalmars-d wrote: Many bug reports and case studies, and often, a persistent voice for minority issues that don't get enough attention. My time spent arguing in this forum is substantial, and as annoying as it may seem, I think if I didn't invest that time, there are things in the past 5-6 years that would have moved in a different direction, and the language would be less attractive to me and my industry as a result. Yes, I am doing pretty much the same. Does that mean I should be more friendly to your lobby of your industry/projects if it directly harms my interests? I have been supporting your push for better low-level control because it helps me too, not because I am kind person. Wasting effort of core contributors on a toolchain I will never use is against my interests and makes me naturally hostile about it. No, I'm not a compiler dev, and I feel like you're trying to discredit me because I'm not. It is exactly what I am trying to do and I am not hiding it. I don't want to be a compiler dev. I want to *use* D to make my life and work easier for my numerous existing projects and commercial activity. I wish I could do the same - I have never wanted to read compiler sources or be part of Phobos dev team. But I do recognize it is the only pragmatical way to make things work as per my needs and it is better to act according to how things are, not how things should have been. No other language community has ever demanded I contribute to the compiler to be eligible to have my case considered relevant. It is not about relevance but about priority. If you are willing to wait for something like 10 years it will surely be addressed at some point. But you demand it being addressed soon, right? And yes, D is probably least staffed language development project among non-hobby projects. If I contributed code to DMD, I know it will become my life, and that means I'm stepping away from my existing interests and areas of development. I'm not interested in doing that. Then you will have to wait until someone appears who have same interests as you but IS willing to start contributing. Surely you can understand that my desire to *use* D as a tool is not at odds with my desire to continue to work in the fields that I prefer to work in? I am simply telling that D is not ready to be used in your industry if you are adamant about such desire. Sad but true. And by complaining you don't improve situation as a whole but simply force redistribution of already existing set of limited resources. I keep asking you simple question you avoid answering - who personally should work to address your concerns? Those are all legit concerns and I doubt anyone would willingly prefer to keep things as they are. But who will do it if apparently you are the person who needs it most and you don't want to do it? Any of the existing dev's that particularly care about the long-term success of the language and the health of the ecosystem? Perhaps new dev's will be attracted by making the ecosystem inclusive of their work and development practice. That tends to be the way open source works no? No, not really. Open source is about people working to fulfill their own personal goals and not minding to share resulting code if it doesn't mean much added effort. Only few care about things like long-term success and only tiny minority will be interested in working on ecosystem they don't use. Motivation you speak about has its place but it is more of a "luxury" contribution that only happens after primary concerns are dealt with. It just happens that if some open-source project is big and mature enough there is a very high chance that your problems are already addressed by someone else. That gives a wrong impression to those who mostly use open-source and rarely contribute. I'm glad you work on the compiler, the community needs people like you more than anyone... I don't really work on compiler, sorry :) although I'm not sure about your attitude. Right now, I'm finding it quite corrosive. Being all kind and nice is not really in my skill set. I hope I have explained better my dislike for this specific set of complaints despite the fact I usually tend to support your cause.
Re: const Propagation
Thank you for your answers. All of your suggestions go into the
right direction, however there's still one thing left that
breakes it: the method itself (blah()) needs to be marked as
const to be callable on a const object. Therefore, I need
something like
void blah(...)(...) if(this ia const object) const : nothing {
}
I would also like to discuss the underlying problem. Even if we
end up finding some syntactic monster to deal with this, there
obviously is no sneaky syntax for it. Am I wrong thinking that is
some very basic type checking problem? I mean, D already
implements const transitively. Thus, if I cast some object to its
const version, all its members magically turn to be const as
well. Wouldn't it be natural to apply this here as well? This
way, I would not even need to declare the lambda's parameter as
const or anything; the compiler would only fail if I actually
pass in something of which the compiler is unsure whether it
changes the passed-in object or not...
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 14:45:37 UTC, Dicebot wrote: On Friday, 26 December 2014 at 01:11:42 UTC, Manu via Digitalmars-d wrote: Many bug reports and case studies, and often, a persistent voice for minority issues that don't get enough attention. My time spent arguing in this forum is substantial, and as annoying as it may seem, I think if I didn't invest that time, there are things in the past 5-6 years that would have moved in a different direction, and the language would be less attractive to me and my industry as a result. Yes, I am doing pretty much the same. Does that mean I should be more friendly to your lobby of your industry/projects if it directly harms my interests? I have been supporting your push for better low-level control because it helps me too, not because I am kind person. Wasting effort of core contributors on a toolchain I will never use is against my interests and makes me naturally hostile about it. No, I'm not a compiler dev, and I feel like you're trying to discredit me because I'm not. It is exactly what I am trying to do and I am not hiding it. I don't want to be a compiler dev. I want to *use* D to make my life and work easier for my numerous existing projects and commercial activity. I wish I could do the same - I have never wanted to read compiler sources or be part of Phobos dev team. But I do recognize it is the only pragmatical way to make things work as per my needs and it is better to act according to how things are, not how things should have been. No other language community has ever demanded I contribute to the compiler to be eligible to have my case considered relevant. It is not about relevance but about priority. If you are willing to wait for something like 10 years it will surely be addressed at some point. But you demand it being addressed soon, right? And yes, D is probably least staffed language development project among non-hobby projects. If I contributed code to DMD, I know it will become my life, and that means I'm stepping away from my existing interests and areas of development. I'm not interested in doing that. Then you will have to wait until someone appears who have same interests as you but IS willing to start contributing. Surely you can understand that my desire to *use* D as a tool is not at odds with my desire to continue to work in the fields that I prefer to work in? I am simply telling that D is not ready to be used in your industry if you are adamant about such desire. Sad but true. And by complaining you don't improve situation as a whole but simply force redistribution of already existing set of limited resources. I keep asking you simple question you avoid answering - who personally should work to address your concerns? Those are all legit concerns and I doubt anyone would willingly prefer to keep things as they are. But who will do it if apparently you are the person who needs it most and you don't want to do it? Any of the existing dev's that particularly care about the long-term success of the language and the health of the ecosystem? Perhaps new dev's will be attracted by making the ecosystem inclusive of their work and development practice. That tends to be the way open source works no? No, not really. Open source is about people working to fulfill their own personal goals and not minding to share resulting code if it doesn't mean much added effort. Only few care about things like long-term success and only tiny minority will be interested in working on ecosystem they don't use. Motivation you speak about has its place but it is more of a "luxury" contribution that only happens after primary concerns are dealt with. It just happens that if some open-source project is big and mature enough there is a very high chance that your problems are already addressed by someone else. That gives a wrong impression to those who mostly use open-source and rarely contribute. I'm glad you work on the compiler, the community needs people like you more than anyone... I don't really work on compiler, sorry :) although I'm not sure about your attitude. Right now, I'm finding it quite corrosive. Being all kind and nice is not really in my skill set. I hope I have explained better my dislike for this specific set of complaints despite the fact I usually tend to support your cause. This is probably the most disgusting, selfish and deluded posts i've read on this entire newsgroup. If D is supposed to supplant C/C++, then the needs of those users *must* be met, especially without deriding those very users. Just because you work on the D ecosystem does not give you 'carte blanche' to tell a user to stop making enquiries into features that are promised by D. The user is the entire goal of D! Forgetting this relegates D to obscurity and makes you look like an ass. No, not really. Open source is about people working to fulfill their own pers
Re: const Propagation
On Monday, 29 December 2014 at 15:17:30 UTC, Julian Kranz wrote:
Thank you for your answers. All of your suggestions go into the
right direction, however there's still one thing left that
breakes it: the method itself (blah()) needs to be marked as
const to be callable on a const object. Therefore, I need
something like
void blah(...)(...) if(this ia const object) const : nothing {
}
Did you try my solutions? It doesn`t need blah to be const
Re: module win32.winioctl :IOCTL_STORAGE_EJECT_MEDIA' Value is Error
On Monday, 29 December 2014 at 12:19:34 UTC, dennis luehring wrote: Am 29.12.2014 um 13:00 schrieb FrankLike: Now,I use the win32.winioctl.d file,find :IOCTL_STORAGE_EJECT_MEDIA ' Value is 0x0202,if you use it ,will get the error value 50.(by GetLastError()). It should be 0x2d4808.If you use it ,it works ok. Why have this kind of mistake? Frank maybe just a bug but https://github.com/Diggsey/druntime-win32/blob/master/winioctl.d seems to be correctly defined IOCTL_STORAGE_EJECT_MEDIA = CTL_CODE_T!(IOCTL_STORAGE_BASE, 0x0202, METHOD_BUFFERED, FILE_READ_ACCESS), You can test to remove a USB by it,use '0x2d4808' will be ok,but '0x0202' will be failed .
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 15:18:57 UTC, Gary Willoughby wrote: This is probably the most disgusting, selfish and deluded posts i've read on this entire newsgroup. I am pretty sure I have written worse. If D is supposed to supplant C/C++, then the needs of those users *must* be met, especially without deriding those very users. Just because you work on the D ecosystem does not give you 'carte blanche' to tell a user to stop making enquiries into features that are promised by D. The user is the entire goal of D! Forgetting this relegates D to obscurity and makes you look like an ass. This is widely advertised statement I can't agree with. For me goal is having working language that works. Getting users is indirect way to achieve that by attracting more contributions but user just by itself has not value to _me_. It is obviously important for Andrei and Walter as D is their project. There are some other contributors which keep being productive despite no obvious personal gain. I admire and respect them but I am not them. And I really hate the culture of hiding own interests just to look all nice. No, not really. Open source is about people working to fulfill their own personal goals and not minding to share resulting code if it doesn't mean much added effort. Only few care about things like long-term success and only tiny minority will be interested in working on ecosystem they don't use. With that paragraph, you've just dumped on Walter, Andrei's and all other open source contributor's efforts for the past n years! How so? Walter and Andrei are not open-source contributors - D is _their_ project. There are some incredible open-source contributors like Kenji, Martin, Vladimir, Daniel - guys with incredible productivity that don't mind help anyone. This is exactly the (awesome) minority. But most people just work on projects they are interested in and occasionally contribute stuff back. Do you disagree that this is the model of D developer community? Or am I the ass because I write it down here instead of acting all idealistic and inspirational?
Re: const Propagation
On Monday, 29 December 2014 at 15:25:13 UTC, Daniel Kozak wrote:
On Monday, 29 December 2014 at 15:17:30 UTC, Julian Kranz wrote:
Thank you for your answers. All of your suggestions go into
the right direction, however there's still one thing left that
breakes it: the method itself (blah()) needs to be marked as
const to be callable on a const object. Therefore, I need
something like
void blah(...)(...) if(this ia const object) const : nothing {
}
Did you try my solutions? It doesn`t need blah to be const
Uuuhm, you're right, it works :-D I don't completely understand
why the compiler does not require the function to be sonst any
longer...
Re: Dgui Will be continue?
On Friday, 26 December 2014 at 22:01:30 UTC, user wrote: don't use crap - use http://forum.dlang.org/thread/ovgoajvboltrtciqf...@forum.dlang.org it is great. works for 64bit!! Thank you,if you have any question,I will help for you. Frank
Re: const Propagation
On 12/29/14 10:36 AM, Julian Kranz wrote:
On Monday, 29 December 2014 at 15:25:13 UTC, Daniel Kozak wrote:
On Monday, 29 December 2014 at 15:17:30 UTC, Julian Kranz wrote:
Thank you for your answers. All of your suggestions go into the right
direction, however there's still one thing left that breakes it: the
method itself (blah()) needs to be marked as const to be callable on
a const object. Therefore, I need something like
void blah(...)(...) if(this ia const object) const : nothing {
}
Not in my solution, because blah is not a "method". T will become const
if the callee is const. As I said, you may have to do T : const(Hugo).
Did you try my solutions? It doesn`t need blah to be const
Uuuhm, you're right, it works :-D I don't completely understand why the
compiler does not require the function to be sonst any longer...
I think Daniel's solution would work if the compiler infers const. I'm
not sure that it does, but if it works, it does :)
The compiler can infer attributes if a function is a template. Not all
attributes, but some of them.
-Steve
Re: Inferred Type for Explicit Cast
On 12/29/14 6:08 AM, Dicebot wrote: On Wednesday, 24 December 2014 at 03:11:40 UTC, Andrei Alexandrescu wrote: On 12/20/14 6:47 PM, Steven Schveighoffer wrote: On 12/20/14 5:20 AM, Dicebot wrote: I'd like to have a cast where you must define both "from" and "to" types precisely. I was actually thinking the same thing. This would be almost future-proof (any changes to either side would result in failed compilation). -Steve Specifying two types instead of one in a "to" call should achieve that. -- Andrei This is different. `to` is about "smart" conversion (and potentially costly with allocations flying around) - we are speaking about same basic dumb cast here, just more controlled. I see. I guess it's easy to add std.conv.explicitCast and std.conv.implicitCast if there's enough impetus for it. -- Andrei
Re: const Propagation
No, actually I don't at all understand why the function does not
need to be const any longer since this code does not compile:
import std.stdio;
class Hugo {
public int x = 42;
void blah(this T)(void function(const Hugo h) f) {
f(this);
}
}
void main() {
Hugo hugo = new Hugo();
const Hugo inge = hugo;
void function(const Hugo h) g = function(const Hugo h) {
write("foobar ");
writeln(h.x);
};
inge.blah(g);
}
Sorry guys, I know I'm a bloody D beginner, ...
Re: const Propagation
Sorry, copy+paste error, I of course meant the following :-/...
import std.stdio;
class Hugo {
public int x = 42;
void blah(void function(const Hugo h) f) {
f(this);
}
}
void main() {
Hugo hugo = new Hugo();
const Hugo inge = hugo;
void function(const Hugo h) g = function(const Hugo h) {
write("foobar ");
writeln(h.x);
};
inge.blah(g);
}
Re: http://wiki.dlang.org/DIP25
On 12/29/14 2:58 AM, John Colvin wrote: On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote: There is a rub though. Not only you're telling what we'd need to do to be more successful, you're also telling us how to do it. Please don't. We are not adding type qualifiers to D if we can avoid it, and generally we want to achieve what we need to achieve with minimum aggravation. Instead please focus on what you're trying to accomplish, not on whether an artifact is a type qualifier or a storage class. Thanks. Andrei But (one of) his point(s) is that the choice between type qualifier and storage class directly impacts his work. Why shouldn't a user express such a point? Making that point is fine so long as the costs are discussed alongside with the applicability to one particular task. -- Andrei
Re: http://wiki.dlang.org/DIP25
On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.
Please comment: http://wiki.dlang.org/DIP25
ref int hun() inout { return b; }
This doesn't make sense. inout cannot cast to mutable.
Yah, the DIP should clarify that new behavior. Thanks. -- Andrei
Re: DIP69 - Implement scope for escape proof references
On Monday, 22 December 2014 at 20:51:46 UTC, Walter Bright wrote:
On 12/22/2014 12:04 AM, Dicebot wrote:
Point of transitive scope is to make easy to expose complex
custom data
structures without breaking memory safety.
I do understand that. Making it work with the type system is
another matter entirely - it's far more complex than just
adding a qualifier. 'inout' looks simple but still has ongoing
issues.
And the thing is, wrappers can be used instead of qualifiers,
in the same places in the same way. It's much simpler.
Ok, lets consider some examples of code I'd want to work with
wrapper approach.
Basic tree structure:
struct Node
{
Node* left, right;
Payload payload;
}
struct Tree
{
Node* root;
}
Restricting public access to nodes to prevent storing persistent
node pointers.
Your proposed approach:
struct Wrapper(T)
{
scope T wrapped;
alias wrapped this;
}
struct Node
{
private:
Node* _left, _right;
public:
auto left() @property { return Wrapper!(Node*)(_left); }
auto right() @property { return Wrapper!(Node*)(_right); }
Payload payload;
}
struct Tree
{
private:
Node* _root;
public:
auto root() @property { return Wrapper!(Node*)(_root); }
}
Am I correct?
If yes, this is exactly the breakage issue I was speaking about :
any code that looked like `is(typeof(Tree.root) == Node*)` will
stop working.
With my latest proposal (pseudo-transitive storage class which is
not part of a type) getters would look simply like `scope Node*
root() @property { return _root; }` and `is(typeof(Tree.root) ==
Node*)` still remained true. Only impact on existing would be
restriction of operations to take address or assign a pointer.
I am pretty sure I am missing many complicated parts here but
this seems like a big deal in retro-fitting existing libraries to
use scope after it was added.
Re: const Propagation
On Monday, 29 December 2014 at 15:53:25 UTC, Steven Schveighoffer wrote: The compiler can infer attributes if a function is a template. Not all attributes, but some of them. -Steve Ah, thanks, this explains it ;-). However, it's kind of uncool that this only works for templates...
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 15:18:57 UTC, Gary Willoughby wrote: This is probably the most disgusting, selfish and deluded posts i've read on this entire newsgroup. If D is supposed to supplant C/C++, then the needs of those users *must* be met, especially without deriding those very users. Just because you work on the D ecosystem does not give you 'carte blanche' to tell a user to stop making enquiries into features that are promised by D. The user is the entire goal of D! Forgetting this relegates D to obscurity and makes you look like an ass. No, not really. Open source is about people working to fulfill their own personal goals and not minding to share resulting code if it doesn't mean much added effort. Only few care about things like long-term success and only tiny minority will be interested in working on ecosystem they don't use. With that paragraph, you've just dumped on Walter, Andrei's and all other open source contributor's efforts for the past n years! I strongly disagree. Dicebot's post is completely true, describing exactly how open source projects actually work, instead of some idealized notion of "Open source it and they will come!" I think some people have unrealistic expectations of open source after the success of past large projects like the linux kernel, gcc, clang, Qt, etc., all of which had heavy commercial support from IBM, Red Hat, Apple, Trolltech/Nokia and so on. D has not reached that stage of commercial support yet, so the expectation that good Windows tooling and support will just magically appear is unrealistic, particularly for free. You are right that the user's needs will ultimately have to be met for D to ever take off to the next level, but I don't recall anyone ever "promising" a good Windows debugging experience, docs that you can learn the language from, or widespread Windows support for D libraries. D is a community project: Manu can note those deficiencies, but as Dicebot said, unless someone wants to work on them or like-minded users pay for someone to do it, the community will generally not just do what he wants. Saying that Dicebot's valid point, that everybody has different goals from open source and most only care about their narrow use case, is dumping on Walter and Andrei's efforts is going off the deep end a bit. I'm sure they are very aware of this reality, and are thankful for the few steady contributors they have.
Re: const Propagation
On Monday, 29 December 2014 at 16:03:41 UTC, Julian Kranz wrote: On Monday, 29 December 2014 at 15:53:25 UTC, Steven Schveighoffer wrote: The compiler can infer attributes if a function is a template. Not all attributes, but some of them. -Steve Ah, thanks, this explains it ;-). However, it's kind of uncool that this only works for templates... If you wish to dig into the details, there's a free ebook with a good explanation here: http://ddili.org/ders/d.en/index.html Search for "this template parameters for member functions" in http://ddili.org/ders/d.en/templates_more.html
Re: http://wiki.dlang.org/DIP25
On 12/29/14 10:51 AM, Andrei Alexandrescu wrote:
On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.
Please comment: http://wiki.dlang.org/DIP25
ref int hun() inout { return b; }
This doesn't make sense. inout cannot cast to mutable.
Yah, the DIP should clarify that new behavior. Thanks. -- Andrei
Huh? This behavior cannot be allowed.
If we can return mutable ref to a member when calling a member function
on a const or immutable object, then we are in violation of const.
What is the point of the above? in such a function, what is typeof(this)?
Even if you can make up rules to make this sane, it's going to be
boatloads more confusing than today's situation with inout.
-Steve
Re: const Propagation
On Monday, 29 December 2014 at 16:03:41 UTC, Julian Kranz wrote: On Monday, 29 December 2014 at 15:53:25 UTC, Steven Schveighoffer wrote: The compiler can infer attributes if a function is a template. Not all attributes, but some of them. -Steve Ah, thanks, this explains it ;-). However, it's kind of uncool that this only works for templates... I've gotten into the habit of templating every function, even if its a zero-parameter template, because trying to manage all the pure/safe/const/nothrow annotations myself always winds up putting me in a corner once the code starts to grow. It's not so bad, really, one advantage is that you can define functions that may or may not compile, but will only trigger an error if they are called on a type that doesn't support it. You can issue compile time branches using "static if (is (typeof(function_name)))" to gain an extra degree of control over this process.
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 16:07:59 UTC, Joakim wrote: I strongly disagree. Dicebot's post is completely true, describing exactly how open source projects actually work, No Dicebot described how open source projects *start*, big difference. I don't want to get into a massive argument here, but viewing users as an inconvenience when developing a project that is (in it's very essence) supposed to be used by them, is a self defeating attitude and will ultimately lead to no-one using it.
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 16:19:35 UTC, Gary Willoughby wrote: On Monday, 29 December 2014 at 16:07:59 UTC, Joakim wrote: I strongly disagree. Dicebot's post is completely true, describing exactly how open source projects actually work, No Dicebot described how open source projects *start*, big difference. I don't want to get into a massive argument here, but viewing users as an inconvenience when developing a project that is (in it's very essence) supposed to be used by them, is a self defeating attitude and will ultimately lead to no-one using it. That is a nice platitude, and one that I actually agreed with above and in general, but who is actually going to do the painstaking work that Windows tooling would require? That is what Dicebot is getting at. If anybody cared about good Windows debugging support or getting vibe.d working flawlessly on Windows, they'd have done it already. Now, Manu might bring more attention to those issues through his post and someone may decide to work on them as a result- it has already spurred Walter to try and improve the phobos docs- which is why I have no problem with his criticism. But Dicebot is right that "users" are not the concern of those outside a small core who contribute to D. Most contributors are just scratching their own itch, and users are just potential suckers who might add other features I want. ;) Also, even companies have to prioritize: they cannot just do whatever the user asks for. Open source projects, which are usually much more resource-constrained, have to prioritize much more. The features Manu asks for have not been deemed priorities. The open source advantage is that the developer pool is potentially much wider, so someone out there may want the same features Manu wants and be willing to implement them.
Re: Inferred Type for Explicit Cast
On Monday, 29 December 2014 at 15:50:15 UTC, Andrei Alexandrescu wrote: I see. I guess it's easy to add std.conv.explicitCast and std.conv.implicitCast if there's enough impetus for it. -- Andrei Yes, exactly. That was why I have asked general opinion about it - don't want to add yet another utility no one uses. I will probably go and just add it anyway : https://github.com/D-Programming-Language/phobos/pull/2822
Re: const Propagation
On Monday, 29 December 2014 at 16:09:33 UTC, Daniel N wrote: On Monday, 29 December 2014 at 16:03:41 UTC, Julian Kranz wrote: On Monday, 29 December 2014 at 15:53:25 UTC, Steven Schveighoffer wrote: The compiler can infer attributes if a function is a template. Not all attributes, but some of them. -Steve Ah, thanks, this explains it ;-). However, it's kind of uncool that this only works for templates... If you wish to dig into the details, there's a free ebook with a good explanation here: http://ddili.org/ders/d.en/index.html Search for "this template parameters for member functions" in http://ddili.org/ders/d.en/templates_more.html Thank you, I should do that :-) Actually, I've read "The D Programming Language" so time ago...
Re: const Propagation
On Monday, 29 December 2014 at 16:13:03 UTC, Vlad Levenfeld wrote: On Monday, 29 December 2014 at 16:03:41 UTC, Julian Kranz wrote: On Monday, 29 December 2014 at 15:53:25 UTC, Steven Schveighoffer wrote: The compiler can infer attributes if a function is a template. Not all attributes, but some of them. -Steve Ah, thanks, this explains it ;-). However, it's kind of uncool that this only works for templates... I've gotten into the habit of templating every function, even if its a zero-parameter template, because trying to manage all the pure/safe/const/nothrow annotations myself always winds up putting me in a corner once the code starts to grow. It's not so bad, really, one advantage is that you can define functions that may or may not compile, but will only trigger an error if they are called on a type that doesn't support it. You can issue compile time branches using "static if (is (typeof(function_name)))" to gain an extra degree of control over this process. Is that really cool? I mean, is wise to have the compiler treat templates and non-templates differently? C++ has tons of such inconsistencies which is the main reason I don't really like C++...
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote: If anybody cared about good Windows debugging support or getting vibe.d working flawlessly on Windows, they'd have done it already. Now, Manu might bring more attention to those issues through his post and someone may decide to work on them as a result- it has already spurred Walter to try and improve the phobos docs- which is why I have no problem with his criticism. Criticism about documentation is actually very well-placed - it is an issue that affects everyone, can be fixed in small chunks and does not require huge effort investment for each chunk. No one loses, everyone wins, yay!
Re: http://wiki.dlang.org/DIP25
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu
wrote:
Walter's reasoning was: we have inout for propagating
qualifiers from a parameter ("this" is also a parameter) to the
output, so we can use it for propagating aliasing information
as well.
Yay! I have been asking for it since scope threads started :)
I like the intention behind the DIP and I think idea itself is
sound and fits naturally into existing language.
But this example confuses me:
@safe ref int wrongIdentity(ref int x) {
return x; // ERROR! Cannot return a ref, please use "ref
inout"
}
@safe ref int identity(ref inout int x) {
return x; // fine
}
If existing meaning of is to be kept too second example should
look like this:
@safe ref inout int identity(ref inout int x) {
return x; // fine
}
otherwise it allows silent casting of const reference to mutable
one!
Re: Worst Phobos documentation evar!
On Sat, Dec 27, 2014 at 05:00:00PM -0800, Walter Bright via Digitalmars-d wrote: > This is so bad there isn't even a direct link to it, it hides in > shame. Just go here: > > http://dlang.org/phobos/std_encoding.html#.transcode > > and scroll up one entry. Here it is: > >size_t encode(Tgt, Src, R)(in Src[] s, R range); > >Encodes c in units of type E and writes the result to the output >range R. Returns the number of Es written. > > Let me enumerate the awesomeness of its awfulness: > > 1. No 'Return:' block, though it obviously returns a value. > 2. No 'Params:' block, though it obviously has parameters. There's a related bug that limits the usefulness of Params blocks: https://issues.dlang.org/show_bug.cgi?id=13270 On another note, the wall-of-text-function-signature complaint that people have voiced can be solved with: https://issues.dlang.org/show_bug.cgi?id=13676 I'll take a stab at this sometime in the near future, but before putting too much time into it, I'd like to know, is this the right direction to go? Will it be approved? There's also a minor cosmetic issue with template ddocs: https://issues.dlang.org/show_bug.cgi?id=13272 T -- Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 14:45:37 UTC, Dicebot wrote: Wasting effort of core contributors on a toolchain I will never use is against my interests and makes me naturally hostile about it. I don't think it needs to be a zero-sum game. Removing blockers to entry can make an orders-of-magnitude difference in the number of users for a particular platform, and when you gain users, you gain developers. Paying now to remove basic usability issues could well free up a lot of core contributor time in future, by opening a door for Windows devs that makes it worth their while to invest effort into the language and its toolchain.
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote: But Dicebot is right that "users" are not the concern of those outside a small core who contribute to D. Most contributors are just scratching their own itch, and users are just potential suckers who might add other features I want. ;) *Stunned* On Monday, 29 December 2014 at 17:57:42 UTC, Joseph Rushton Wakeling wrote: I don't think it needs to be a zero-sum game. Removing blockers to entry can make an orders-of-magnitude difference in the number of users for a particular platform, and when you gain users, you gain developers. Paying now to remove basic usability issues could well free up a lot of core contributor time in future, by opening a door for Windows devs that makes it worth their while to invest effort into the language and its toolchain. Yes, this is how i see things.
Re: Inferred Type for Explicit Cast
On Monday, 29 December 2014 at 16:45:31 UTC, Dicebot wrote: On Monday, 29 December 2014 at 15:50:15 UTC, Andrei Alexandrescu wrote: I see. I guess it's easy to add std.conv.explicitCast and std.conv.implicitCast if there's enough impetus for it. -- Andrei Yes, exactly. That was why I have asked general opinion about it - don't want to add yet another utility no one uses. I will probably go and just add it anyway : https://github.com/D-Programming-Language/phobos/pull/2822 +1
Re: Worst Phobos documentation evar!
On Monday, 29 December 2014 at 05:39:16 UTC, Walter Bright wrote: On 12/28/2014 8:44 AM, Kiith-Sa wrote: It depends on the function being documented. For 'downcase', such blocks are overkill; After doing it both ways for a while, I'm pretty convinced they are not overkill even for trivial functions: 1. they lend an air of consistency and comfort to the reader 2. they provide an anchor for automated tools which can extract the information 3. without such a block, I've found that I (and others, http://dlang.org/phobos/std_algorithm.html#.sort) tend to omit descriptions of 'obvious' parameters which are actually not obvious at all. 4. a block can be styled in a custom manner DDoc is powerful, but it is a very nasty case of "hard things are possible, easy things are hard" (e.g. tables, and very unreadable in source $(B bold) instead of **bold**, $(D code) instead of `code`, $(LINK2 ...), etc. . Having used both Ddoc and Markdown, I seriously disagree with this. Take a look at the markdown source for DIP69. It's horrific. I think it'd be a good idea to add at least a subset of markdown to DMD DDoc, which could generate DDoc macros (e.g. **bold**, *italic*, `inline code` (DDoc already has nice syntax for code *blocks*), [link](www.link.com), and some table syntax (not in vanilla markdown, but e.g. GitHub markdown/PanDoc markdown have a common syntax) - I may be able to find some time to work on this for DMD DDoc in summer (not sooner unfortunately, I'd need some time to look around the code as I never touched it), but would it have a chance of being merged? (Walter?) I'd rather not accept some Markdown dialect into Ddoc. I like your sense of the compromise. DDoc is mostly usefull to generate the doc as html but inside the sources, it's often **unreadable**. I think that you know that documentation comments as markdow would be good but maybe you're scared because of the consequences implied when rendering dlang.org std reference and such things. And if both could live together ? If I had the power to do this, DDoc would be primilarly 'markdown' with optionally html and macros things allowed.
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 15:34:44 UTC, Dicebot wrote: On Monday, 29 December 2014 at 15:18:57 UTC, Gary Willoughby wrote: This is probably the most disgusting, selfish and deluded posts i've read on this entire newsgroup. I am pretty sure I have written worse. Time out, everyone. I really don't see any benefit to throwing around any more personalized criticism; it achieves nothing other than demotivation. This is widely advertised statement I can't agree with. For me goal is having working language that works. Getting users is indirect way to achieve that by attracting more contributions but user just by itself has not value to _me_. An indirect benefit is still a benefit -- as I said in my previous post, these things aren't a zero-sum game. Among other things, more users means not only the likelihood of more contributions, but also more bugs and points of failure identified, more experienced people to use as a sounding board for ideas, more people to call on for help when you have a problem, and so on. And I really hate the culture of hiding own interests just to look all nice. It's fine to be self-interested, but it is important to know where your _real_ self-interest lies, and that usually involves looking out for the interests of others too. :-) How so? Walter and Andrei are not open-source contributors - D is _their_ project. I think the better line to draw here is between project leadership and community contributions -- after all, everyone is contributing open source code here. Do you disagree that this is the model of D developer community? Or am I the ass because I write it down here instead of acting all idealistic and inspirational? I think there is a lot of misunderstanding arising here, because I think you are saying "I think this is how things actually work in practice" (arguable in the case of D, but probably true for many open source projects) and that's being mistaken for "I think this is how things ought to work." I guess what I'd say is that, yes, I get how the idealistic and inspirational stuff can be irritating and feel like delusion, but it can be a pretty powerful tool to help facilitate the process of cooperation between different people who do indeed all have different itches to scratch. Being "nice" isn't just a matter of being liked or not (not the most important thing in the world); it's a really handy means of minimizing the amount of unnecessary friction in a community. It doesn't need to involve any rose-tinted spectacles or illusions about people's motivations, just a recognition of what is going to help promote positive or negative reactions from other people.
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 18:42:17 UTC, Joseph Rushton Wakeling wrote: On Monday, 29 December 2014 at 15:34:44 UTC, Dicebot wrote: This is widely advertised statement I can't agree with. For me goal is having working language that works. Getting users is indirect way to achieve that by attracting more contributions but user just by itself has not value to _me_. An indirect benefit is still a benefit -- as I said in my previous post, these things aren't a zero-sum game. Among other things, more users means not only the likelihood of more contributions, but also more bugs and points of failure identified, more experienced people to use as a sounding board for ideas, more people to call on for help when you have a problem, and so on. It also means more people asking for stuff, then doing nothing to contribute towards it, as though the D community is their slave labor. Not saying this about Manu, just that there are people with weird expectations of open source. I guess what I'd say is that, yes, I get how the idealistic and inspirational stuff can be irritating and feel like delusion, but it can be a pretty powerful tool to help facilitate the process of cooperation between different people who do indeed all have different itches to scratch. Being "nice" isn't just a matter of being liked or not (not the most important thing in the world); it's a really handy means of minimizing the amount of unnecessary friction in a community. It doesn't need to involve any rose-tinted spectacles or illusions about people's motivations, just a recognition of what is going to help promote positive or negative reactions from other people. I'll add that a majority of contributors do not solely scratch their own itches, but contribute in other ways that do not directly benefit them. Maybe that's because there are indirect benefits to having better docs, or they just become invested in the project over time. Very few operate solely from self-interest, though most probably contribute a majority of their work for that reason.
Re: http://wiki.dlang.org/DIP25
On 12/29/14 8:09 AM, Steven Schveighoffer wrote:
On 12/29/14 10:51 AM, Andrei Alexandrescu wrote:
On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.
Please comment: http://wiki.dlang.org/DIP25
ref int hun() inout { return b; }
This doesn't make sense. inout cannot cast to mutable.
Yah, the DIP should clarify that new behavior. Thanks. -- Andrei
Huh? This behavior cannot be allowed.
If we can return mutable ref to a member when calling a member function
on a const or immutable object, then we are in violation of const.
What is the point of the above? in such a function, what is typeof(this)?
Even if you can make up rules to make this sane, it's going to be
boatloads more confusing than today's situation with inout.
I tend to agree. You seem to have shown that reusing inout for scope
information becomes confusing. -- Andrei
Re: http://wiki.dlang.org/DIP25
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu wrote: I tend to agree. You seem to have shown that reusing inout for scope information becomes confusing. -- Andrei What is the problem with using inout exactly as it is now (== both for argument and return type) but defining it to propagate aliasing information as it is decribed in DIP25?
Re: Inferred Type for Explicit Cast
On 12/29/14 10:14 AM, Jonathan Marler wrote: On Monday, 29 December 2014 at 16:45:31 UTC, Dicebot wrote: On Monday, 29 December 2014 at 15:50:15 UTC, Andrei Alexandrescu wrote: I see. I guess it's easy to add std.conv.explicitCast and std.conv.implicitCast if there's enough impetus for it. -- Andrei Yes, exactly. That was why I have asked general opinion about it - don't want to add yet another utility no one uses. I will probably go and just add it anyway : https://github.com/D-Programming-Language/phobos/pull/2822 +1 If you like it, please review it. It took me all of 30 seconds to find a typo. Thanks. -- Andrei
Re: const Propagation
On Monday, 29 December 2014 at 14:13:20 UTC, Daniel Kozak wrote:
On Monday, 29 December 2014 at 13:22:41 UTC, Julian Kranz wrote:
So I hope you understand; I've got no problem with changing
the type of the function g as you supposed. The bad thing is
the additional overload that results in duplicated code.
So you can write something like this:
import std.stdio;
class Hugo {
public int x = 42;
void blah(this T)(void function(T h) f)
{
f(this);
}
}
void main() {
Hugo hugo = new Hugo();
void function(Hugo h) f = function(Hugo h) {
h.x = 99;
};
hugo.blah(f);
const Hugo inge = hugo;
void function(const Hugo h) g = function(const Hugo h) {
writeln("foobar");
};
inge.blah(g);
}
So template methods deduce const now? Sweet.
I see one wart on this: `inge.blah((h) {});` doesn't work.
Re: const Propagation
On Monday, 29 December 2014 at 13:20:39 UTC, Julian Kranz wrote:
Thank you for your answer. This kind of thing also works for
C++, but that would mean that I would implement the whole
visitor twice - one const and one non-const version. Is that
really the only way? Can't I tell the D compiler that "the
argument of that lambda shares the const-ness of the current
object"?
D offers "inout"; this actually aims into the right directing,
but I guess it does not help here.
Is there any "static if"-something construct to check the
const-ness of an object?
There's a pattern I suggested before[1] that I'd like to mention
in addition to the template solutions Steven Schveighoffer and
Daniel Kozak gave:
Call the non-const overload from the const overload and cast
accordingly.
In your case:
void blah(void function(Hugo h) f) {
f(this);
}
void blah(void function(const Hugo h) f) const {
(cast(Hugo) this).blah(cast(void function(Hugo)) f);
}
This is safe as long as the non-const overload does not mutate
the object when f doesn't. BUT you have to make sure of that
yourself; the compiler can't help anymore.
[1]
http://stackoverflow.com/questions/22442031/how-to-make-a-template-function-const-if-the-template-is-true/22442425#22442425
Re: Lost a new commercial user this week :(
On 12/29/14 10:58 AM, Joakim wrote: On Monday, 29 December 2014 at 18:42:17 UTC, Joseph Rushton Wakeling wrote: On Monday, 29 December 2014 at 15:34:44 UTC, Dicebot wrote: This is widely advertised statement I can't agree with. For me goal is having working language that works. Getting users is indirect way to achieve that by attracting more contributions but user just by itself has not value to _me_. An indirect benefit is still a benefit -- as I said in my previous post, these things aren't a zero-sum game. Among other things, more users means not only the likelihood of more contributions, but also more bugs and points of failure identified, more experienced people to use as a sounding board for ideas, more people to call on for help when you have a problem, and so on. It also means more people asking for stuff, then doing nothing to contribute towards it, as though the D community is their slave labor. If we, the D community, want D to succeed, we must change this attitude. -- Andrei
Re: Lost a new commercial user this week :(
On Mon, 29 Dec 2014 15:18:56 + Gary Willoughby via Digitalmars-d wrote: > This is probably the most disgusting, selfish and deluded posts > i've read on this entire newsgroup. fsck. i was sure that this was written about me. i sucked again. > If D is supposed to supplant C/C++, then the needs of those users > *must* be met, especially without deriding those very users. Just > because you work on the D ecosystem does not give you 'carte > blanche' to tell a user to stop making enquiries into features > that are promised by D. but it gives! this is at least honest, unlike writing in bugzilla that it is intended for patches and then telling "github or GTFO, nobody will work with the code in bugzilla!" i prefer to read a honest truth, not polite lies. > The user is the entire goal of D! i don't know what goal "D" has and how it can has any goals at all, but now you are telling Dicebot that he must work *not* on what *he* wants, but on something that some random user wants. more of it, you trying to tell him that he should shut up. and all this without him even being your employee. THIS is what i call "disgusting, selfish and deluded post". > > No, not really. Open source is about people working to fulfill > > their own personal goals and not minding to share resulting > > code if it doesn't mean much added effort. Only few care about > > things like long-term success and only tiny minority will be > > interested in working on ecosystem they don't use. > With that paragraph, you've just dumped on Walter, Andrei's and > all other open source contributor's efforts for the past n years! and again... maybe i didn't understand you right and "This is probably the most disgusting, selfish and deluded posts i've read on this entire newsgroup" was about your post i'm answering to? but why plurar "posts" then? please, explain me, *whose* exactly post was "disgusting, selfish and deluded"? 'cause now i'm completely lost. signature.asc Description: PGP signature
Current status of release
I'm wondering where we currently are on the process of releasing 2.067 ? The reference page http://wiki.dlang.org/Beta_Testing#Available_Downloads , is horribly outdated, as DMD v2.066.1 was released, all known regressions are marked as fixed on Bugzilla, and page's last modification date is 20/09. The http://wiki.dlang.org/Agenda don't help, either. I know Andrew Edwards did a wonderful job taking care of this, and that he's now busy. Did someone take over this job ?
Re: Worst Phobos documentation evar!
On 12/29/2014 3:19 AM, Jacob Carlborg wrote: On 2014-12-29 06:39, Walter Bright wrote: Having used both Ddoc and Markdown, I seriously disagree with this. Take a look at the markdown source for DIP69. It's horrific. Do you mean on the wiki? The wiki doesn't use Markdown. At least not anyone I've seen. It uses something pretty similar. They all kinda mush together in my mind :-(
Re: Worst Phobos documentation evar!
On 12/29/2014 10:34 AM, jklp wrote: I like your sense of the compromise. DDoc is mostly usefull to generate the doc as html but inside the sources, it's often **unreadable**. I think that you know that documentation comments as markdow would be good but maybe you're scared because of the consequences implied when rendering dlang.org std reference and such things. And if both could live together ? If I had the power to do this, DDoc would be primilarly 'markdown' with optionally html and macros things allowed. I don't care much for hybrids, they are confusing and ugly.
Re: http://wiki.dlang.org/DIP25
On 12/29/2014 5:53 AM, Steven Schveighoffer wrote: On 12/28/14 4:33 PM, Walter Bright wrote: inout is not transitive, so a ref on the container doesn't apply to a ref on the contents if there's another level of indirection in there. I'm not sure what you mean by this, but inout as a type modifier is definitely transitive. As a type modifier, yes, it is transitive. As transferring lifetime to the return value, it is not.
Re: http://wiki.dlang.org/DIP25
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout for scope
information becomes confusing. -- Andrei
What is the problem with using inout exactly as it is now (== both for
argument and return type) but defining it to propagate aliasing
information as it is decribed in DIP25?
It can, and I don't have a problem for that.
But I think disallowing:
ref T foo(T)(ref T t) { return t;}
Is no good. The DIP seems to be indicating inout can have another use
that has nothing to do with const, but I'm not exactly sure.
Ironically, inout used to be an alias for ref :)
-Steve
Re: Documenting parameters [was: Re: Worst Phobos documentation evar!]
On 12/29/2014 3:24 AM, Joseph Rushton Wakeling wrote: On Monday, 29 December 2014 at 00:50:10 UTC, Walter Bright wrote: It's already possible. Change the macro definitions in the std.ddoc file. Sure. But I did think it might be a good idea to discuss things here first before jumping into changing anything. After all, you might have good reasons for the current defaults being as they are. The current defaults make it work without needing a style sheet. That's pretty much the reason why they are the way they are.
Re: const Propagation
On Mon, 29 Dec 2014 15:36:57 +
Julian Kranz via Digitalmars-d wrote:
> Uuuhm, you're right, it works :-D I don't completely understand
> why the compiler does not require the function to be sonst any
> longer...
we must get our big red letters and write somewhere: "template is not
XXX", where XXX is anything of function, method, struct, class, etc. ;-)
eponymous template syntax make people believe that `a()() {...}` is a
function, while it's not. this is template, and it has template magic in
in.
this is not your fault though. this is not a fault of anyone for that
matter: it was designed to look like function, so it does. alas, we
can't have it looking as a function and not confusing newcomers in the
same time.
eventually you will start to easily recognize such "non-XXX" templates.
i daresay that D is all about templates, so you have no other
choice. ;-)
signature.asc
Description: PGP signature
Re: http://wiki.dlang.org/DIP25
On Monday, 29 December 2014 at 19:54:33 UTC, Steven Schveighoffer
wrote:
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei
Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout
for scope
information becomes confusing. -- Andrei
What is the problem with using inout exactly as it is now (==
both for
argument and return type) but defining it to propagate aliasing
information as it is decribed in DIP25?
It can, and I don't have a problem for that.
But I think disallowing:
ref T foo(T)(ref T t) { return t;}
Is no good.
It is to be disallowed only in @safe code, right?
The DIP seems to be indicating inout can have another use that
has nothing to do with const, but I'm not exactly sure.
I see its potential as a generic wildcard for
attribute/qualifier propagation through the functions.
Re: Documenting parameters [was: Re: Worst Phobos documentation evar!]
On Monday, 29 December 2014 at 19:51:26 UTC, Walter Bright wrote: The current defaults make it work without needing a style sheet. That's pretty much the reason why they are the way they are. You could also just bundle a stylesheet with it, which would be the best of both worlds. Have the semantic tags in the main macros and the style as an embedded
Re: Lost a new commercial user this week :(
I'd better respond when I will not be as angry and tempted to go into accusation mode.
Re: Current status of release
On Monday, 29 December 2014 at 19:40:41 UTC, Mathias LANG wrote: I'm wondering where we currently are on the process of releasing 2.067 ? The reference page http://wiki.dlang.org/Beta_Testing#Available_Downloads , is horribly outdated, as DMD v2.066.1 was released, all known regressions are marked as fixed on Bugzilla, and page's last modification date is 20/09. The http://wiki.dlang.org/Agenda don't help, either. I know Andrew Edwards did a wonderful job taking care of this, and that he's now busy. Did someone take over this job ? Martin Nowak took it over to finish 2.066.1 but I don't remember him mentioning anything about 2.067
Re: Worst Phobos documentation evar!
On 2014-12-29 20:48, Walter Bright wrote: I don't care much for hybrids, they are confusing and ugly. Markdown already support raw HTML. We could use Markdown but with Ddoc macros instead of raw HTML. BTW, Ddoc macros are really ugly. -- /Jacob Carlborg
Re: const Propagation
Thanks again for all answers :-).
On Monday, 29 December 2014 at 19:57:20 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 29 Dec 2014 15:36:57 +
Julian Kranz via Digitalmars-d
wrote:
Uuuhm, you're right, it works :-D I don't completely
understand why the compiler does not require the function to
be sonst any longer...
we must get our big red letters and write somewhere: "template
is not
XXX", where XXX is anything of function, method, struct, class,
etc. ;-)
eponymous template syntax make people believe that `a()()
{...}` is a
function, while it's not. this is template, and it has template
magic in
in.
this is not your fault though. this is not a fault of anyone
for that
matter: it was designed to look like function, so it does.
alas, we
can't have it looking as a function and not confusing newcomers
in the
same time.
eventually you will start to easily recognize such "non-XXX"
templates.
i daresay that D is all about templates, so you have no other
choice. ;-)
Well, of course you're right; but the thing is - does it really
make sense to have a less powerful semantic for functions here?
Does it help in any way? I mean, if something works just because
you're using a template, it should maybe also work if you're
not...
Re: Worst Phobos documentation evar!
On 2014-12-29 20:47, Walter Bright wrote: It uses something pretty similar. They all kinda mush together in my mind :-( Don't blame Markdown just because some other markup language you don't like looks similar to you. -- /Jacob Carlborg
Re: const Propagation
On Mon, 29 Dec 2014 16:48:45 +
Julian Kranz via Digitalmars-d wrote:
> Is that really cool? I mean, is wise to have the compiler treat
> templates and non-templates differently? C++ has tons of such
> inconsistencies which is the main reason I don't really like
> C++...
ah. "templates are not functions!" ;-)
this is completely unpractical to forbid compiler doing attribute
inference on templates: it's not always possible to manually attribute
template. for example:
void a(T) (T n) {
...some code 1
static if (isThisSomething!T) {
...some code 2
}
...some code 3
}
'...some code 2' may be used only for specific types and it can be
non-safe, and '...some code 1' and '...some code 2' is always safe. yet
we can't mark the template with `@safe` here, we must copy-paste the
whole template code: once for `@system` variant and once for `@safe`
variant. this will effectively kill the template handyness.
as for functions... function attributes are the part of it's signature.
see: `void a ();` is not the same function as `void a () @safe;`. they
has different signatures and different name mangling. this can't be
avoided, as linker has to link the correct implementation, and linker
has no clue about D, it sees only mangled function names. so
technically compiler can do attribute inference on functions, but
practically it is impossible, as attributes depends of the call site,
and compiler has to generate function signature BEFORE it is called.
that's why i'm emphasising "template is not XXX" sentense. template is
a template, it's not a function. don't let it trick you! ;-)
signature.asc
Description: PGP signature
Re: const Propagation
On Mon, 29 Dec 2014 20:01:59 + Julian Kranz via Digitalmars-d wrote: > Well, of course you're right; but the thing is - does it really > make sense to have a less powerful semantic for functions here? > Does it help in any way? I mean, if something works just because > you're using a template, it should maybe also work if you're > not... see my another reply. internally templates generates functions with different signatures, 'cause compiler must know the signature to tell the caller what exactly it is calling. ;-) templates was born to overcome this limitation. ;-) signature.asc Description: PGP signature
Re: const Propagation
On Monday, 29 December 2014 at 16:48:46 UTC, Julian Kranz wrote: Is that really cool? I mean, is wise to have the compiler treat templates and non-templates differently? C++ has tons of such inconsistencies which is the main reason I don't really like C++... Well, it is reasonable in light of the fact that templates require the source to be available (which guarantees the compiler can analyze it) while regular functions might not be (e.g. if they are in a precompiled library). In this sense, making a function into a zero-param template is equivalent to telling the compiler that it is free to analyze the source. That being said, I sympathize with the sentiment - it would be more consistent if all functions whose source was available could be auto-annotated. I'm not sure what the technical impediments to this might be, though. Still, adding an extra () to the function signature is not too inconvenient, and carries some additional benefits. I find annotations and qualifiers to be part of the "ugly" side of D, and try to avoid using them (took me awhile to figure out that C++ style const-correctness doesn't work in D, due to transitivity) but I'm afraid don't know enough about compilers to make a more informed judgement than "that's just how it is." Maybe someone with more experience in this area could weigh in?
Re: Lost a new commercial user this week :(
On Monday, 29 December 2014 at 19:34:52 UTC, ketmar via Digitalmars-d wrote: please, explain me, *whose* exactly post was "disgusting, selfish and deluded"? 'cause now i'm completely lost. Ok, i will explain because i think my point should be made clear and because this thread is giving valuable feedback (from Manu) to the D community about a missed opportunity in industry! I have no argument with people contributing to D to further their interests. That is what (i'm guessing) pushes most open source projects forward. What i firmly object to and what i find very degrading is that because certain people make contributions to D it gives them such arrogance as to espouse their personal motivations as the overall goal and motivations of D. Also in the process trying to persuade other (non-contributing) users that their expectations are illegitimate or somehow lesser in importance. D, as a project, already has a firmly entrenched goal and it's motivation is to reach that goal. Anyone contributing to D must acknowledge that goal and be prepared to sustain it through their contributions. The goal is set by Walter and Andrei. The goals are (mostly) outlined here: http://dlang.org/overview.html When someone enquires about the progress of a particular feature they do not need to hear "contribute or gtfo". What they need is a civil answer preferably pointing to a roadmap. Some recent users are becoming very vocal, especially regarding memory allocation regarding GC, RC, etc. because D is being pushed towards the C++ crowd and this is what they expect to be able to control. It is marketed as a system programming language, like it or not. These users expect full control. Of course this is a work in progress. (@nogc, etc.) I know that, you know that, but they don't. Please don't say "I contribute and you don't so shut up". It make the entire community look like massive dicks. Yes, i know that some users are always pushing for the same features to be implemented and others just what some features to be actually finished, me too! but this is no reason to give them attitude and tell them to contribute or gtfo. Some people just aren't capable of contributing (me included). But that doesn't render their requests moot! Especially when their expectations are included in the goals of D. I want to contribute, i want to push D forward, i'm slowly educating myself to a standard where i'm comfortable to be able to do so. This constant attitude however just makes me want to concentrate on other languages.
Re: const Propagation
On Mon, 29 Dec 2014 20:07:08 + evenex via Digitalmars-d wrote: > > Is that really cool? I mean, is wise to have the compiler treat > > templates and non-templates differently? C++ has tons of such > > inconsistencies which is the main reason I don't really like > > C++... > > Well, it is reasonable in light of the fact that templates > require the source to be available (which guarantees the compiler > can analyze it) while regular functions might not be (e.g. if > they are in a precompiled library). In this sense, making a > function into a zero-param template is equivalent to telling the > compiler that it is free to analyze the source. > That being said, I sympathize with the sentiment - it would be > more consistent if all functions whose source was available could > be auto-annotated. I'm not sure what the technical impediments to > this might be, though. Still, adding an extra () to the function > signature is not too inconvenient, and carries some additional > benefits. > I find annotations and qualifiers to be part of the "ugly" side > of D, and try to avoid using them (took me awhile to figure out > that C++ style const-correctness doesn't work in D, due to > transitivity) but I'm afraid don't know enough about compilers to > make a more informed judgement than "that's just how it is." > Maybe someone with more experience in this area could weigh in? you get it right. ;-) signature.asc Description: PGP signature
Re: const Propagation
On 12/29/14 2:07 PM, anonymous wrote:
On Monday, 29 December 2014 at 13:20:39 UTC, Julian Kranz wrote:
Thank you for your answer. This kind of thing also works for C++, but
that would mean that I would implement the whole visitor twice - one
const and one non-const version. Is that really the only way? Can't I
tell the D compiler that "the argument of that lambda shares the
const-ness of the current object"?
D offers "inout"; this actually aims into the right directing, but I
guess it does not help here.
Is there any "static if"-something construct to check the const-ness
of an object?
There's a pattern I suggested before[1] that I'd like to mention
in addition to the template solutions Steven Schveighoffer and
Daniel Kozak gave:
Call the non-const overload from the const overload and cast
accordingly.
In your case:
void blah(void function(Hugo h) f) {
f(this);
}
void blah(void function(const Hugo h) f) const {
(cast(Hugo) this).blah(cast(void function(Hugo)) f);
}
The problem here is, you lose your compiler checks. It's not so much
that "I know at this moment, mutable blah does not change anything",
it's "I know at this moment, and anytime in the future, mutable blah
does not change anything".
Hm... I did think of another solution, using delegates:
private void blahImpl(scope void delegate() f) const {
... // do things that don't change this
f();
... // do things that don't change this
}
void blah(void function(Hugo h) f) {
blahImpl((){f(this);});
}
And this time, I did test it, because I was curious enough :)
While you still need the boilerplate of repeating blah for const and
others, you don't need to repeat the larger implementation. One thing
you could do is make blah a template which takes Hugo as a template
type, and then any function that accepts a Hugo (including a base class)
would be usable, and it then allows you to avoid repetition:
void blah(T)(void function(T t) f) {
blahImpl((){f(this);});
}
except... drat, it doesn't compile, can't deduce T when it's const(Hugo)
(that doesn't make much sense). I'll look and see if there is an open
bug report.
-Steve
Re: const Propagation
On 12/29/14 3:11 PM, Steven Schveighoffer wrote:
On 12/29/14 2:07 PM, anonymous wrote:
On Monday, 29 December 2014 at 13:20:39 UTC, Julian Kranz wrote:
Thank you for your answer. This kind of thing also works for C++, but
that would mean that I would implement the whole visitor twice - one
const and one non-const version. Is that really the only way? Can't I
tell the D compiler that "the argument of that lambda shares the
const-ness of the current object"?
D offers "inout"; this actually aims into the right directing, but I
guess it does not help here.
Is there any "static if"-something construct to check the const-ness
of an object?
There's a pattern I suggested before[1] that I'd like to mention
in addition to the template solutions Steven Schveighoffer and
Daniel Kozak gave:
Call the non-const overload from the const overload and cast
accordingly.
In your case:
void blah(void function(Hugo h) f) {
f(this);
}
void blah(void function(const Hugo h) f) const {
(cast(Hugo) this).blah(cast(void function(Hugo)) f);
}
The problem here is, you lose your compiler checks. It's not so much
that "I know at this moment, mutable blah does not change anything",
it's "I know at this moment, and anytime in the future, mutable blah
does not change anything".
Hm... I did think of another solution, using delegates:
private void blahImpl(scope void delegate() f) const {
... // do things that don't change this
f();
... // do things that don't change this
}
void blah(void function(Hugo h) f) {
blahImpl((){f(this);});
}
And this time, I did test it, because I was curious enough :)
While you still need the boilerplate of repeating blah for const and
others, you don't need to repeat the larger implementation. One thing
you could do is make blah a template which takes Hugo as a template
type, and then any function that accepts a Hugo (including a base class)
would be usable, and it then allows you to avoid repetition:
void blah(T)(void function(T t) f) {
blahImpl((){f(this);});
}
except... drat, it doesn't compile, can't deduce T when it's const(Hugo)
(that doesn't make much sense). I'll look and see if there is an open
bug report.
OK, it's not inferring the const on 'this'. It ONLY does this if you
have a 'this' template parameter in the template list. This works:
void blah(T, this _)(void function(T t) f)
interesting, can someone explain this requirement?
-Steve
Re: http://wiki.dlang.org/DIP25
On 12/29/14 2:57 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:54:33 UTC, Steven Schveighoffer wrote:
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout for scope
information becomes confusing. -- Andrei
What is the problem with using inout exactly as it is now (== both for
argument and return type) but defining it to propagate aliasing
information as it is decribed in DIP25?
It can, and I don't have a problem for that.
But I think disallowing:
ref T foo(T)(ref T t) { return t;}
Is no good.
It is to be disallowed only in @safe code, right?
Even in safe code, if it's safe to do so, it should be allowed.
I think the driving point behind this push is that when you see:
ref T foo(ref T t);
how do you know if the return of foo is somehow related to t or not? The
DIP is saying if you return something related to t, you have to mark t
as inout. At least, this is my understanding. But this precludes doing
anything with a mutable t inside foo, since inout means "const within
the function".
The DIP seems to be indicating inout can have another use that has
nothing to do with const, but I'm not exactly sure.
I see its potential as a generic wildcard for attribute/qualifier
propagation through the functions.
It's not generic at all. It's a concrete type qualifier that does not
generate a template. When inside an 'inout' function, anything marked as
inout is transitively const.
-Steve
Re: http://wiki.dlang.org/DIP25
On 12/29/14 2:50 PM, Walter Bright wrote: On 12/29/2014 5:53 AM, Steven Schveighoffer wrote: On 12/28/14 4:33 PM, Walter Bright wrote: inout is not transitive, so a ref on the container doesn't apply to a ref on the contents if there's another level of indirection in there. I'm not sure what you mean by this, but inout as a type modifier is definitely transitive. As a type modifier, yes, it is transitive. As transferring lifetime to the return value, it is not. I strongly suggest not to use inout to mean this. This idea would be a disaster. -Steve
Re: Lost a new commercial user this week :(
On Mon, 29 Dec 2014 20:09:08 + Gary Willoughby via Digitalmars-d wrote: > D, as a project, already has a firmly entrenched goal and it's > motivation is to reach that goal. Anyone contributing to D must > acknowledge that goal and be prepared to sustain it through their > contributions. The goal is set by Walter and Andrei. The goals > are (mostly) outlined here: http://dlang.org/overview.html 1. i can't see anything about "user-oriented" there. 2. if i don't care about anything written there, i should not contribute? you keep saying "do as we say or GTFO"... > When someone enquires about the progress of a particular feature > they do not need to hear "contribute or gtfo". What they need is > a civil answer preferably pointing to a roadmap. ...and that roadmap has only three words on it: "contribute or GTFO". > Please don't say "I contribute and you don't so > shut up". It make the entire community look like massive dicks. it's better to be dick than to be a liar. it's obvious that we haven't enough resources to comply with all user requests, so it's honest to say: "if you want it -- DIY! otherwise it's unlikely to happen soon". we are not a bunch of marketing shitheads, we MUST tell people the truth, not tricking people so they will wait for something to happen and then will go out frustrated by lies. > Some people just > aren't capable of contributing (me included). But that doesn't > render their requests moot! anyone is capable of contributing, it's not necessary about writing a code. if enough people want some feature that developers aren't able to deliver now, those people can cooperate and hire some programmer(s) to implement the feature. i can assure you that this way they will get their beloved feature much faster than by simply talking about how it's missing. open-source is not about shouting in the box and then magically getting result out of it. to get something you have either to put something in or just silently wait until someone else will put something into the box. shouting in the box will do nothing. > I want to contribute, i want to push D forward, i'm slowly > educating myself to a standard where i'm comfortable to be able > to do so. This constant attitude however just makes me want to > concentrate on other languages. ah, the question is WHY do you want to contribute? what output you want to get from being a contributor? i'm not trying to insult you here, it's really important. signature.asc Description: PGP signature
Re: http://wiki.dlang.org/DIP25
On Monday, 29 December 2014 at 20:20:45 UTC, Steven Schveighoffer wrote: But this precludes doing anything with a mutable t inside foo, since inout means "const within the function". Hm, yes, this is indeed quite the problem. I have totally forgot that compiler has no means of figuring out which invocation of inout is currently used. But something very similar feels necessary to me. There is constness, lifetime, purity - inventing new dedicated keyword for each case does not feel like scaling approach. Especially when existing one is named so generic.
Re: Worst Phobos documentation evar!
On Monday, 29 December 2014 at 17:38:42 UTC, H. S. Teoh via Digitalmars-d wrote: Most Phobos range functions return opaque types that the user should not depend on (even if the type is nameable), since the point of the range API is to have user code Just Work(tm) without needing to know the actual type of the returned object. That's not something we should assume a new D user will know. Someone with a few years of C++ experience will probably be okay, but that's kind of my point - the documentation shouldn't require that background. I can imagine someone seeing examples that use auto with ranges and then asking "Now what?" Those are the frustrations that make users give up on the language.
Re: Worst Phobos documentation evar!
On Mon, 29 Dec 2014 21:10:15 + bachmeier via Digitalmars-d wrote: > That's not something we should assume a new D user will know. > Someone with a few years of C++ experience will probably be okay, > but that's kind of my point - the documentation shouldn't require > that background. I can imagine someone seeing examples that use > auto with ranges and then asking "Now what?" Those are the > frustrations that make users give up on the language. trying to use the language one didn't even bother to learn will inevitably lead to frustration. first time i tried to use Forth was... painful. but it was Z80 machine and i have no other sane choices, so now i love Forth. signature.asc Description: PGP signature
Re: http://wiki.dlang.org/DIP25
On 12/29/14 3:42 PM, Dicebot wrote: On Monday, 29 December 2014 at 20:20:45 UTC, Steven Schveighoffer wrote: But this precludes doing anything with a mutable t inside foo, since inout means "const within the function". Hm, yes, this is indeed quite the problem. I have totally forgot that compiler has no means of figuring out which invocation of inout is currently used. But something very similar feels necessary to me. There is constness, lifetime, purity - inventing new dedicated keyword for each case does not feel like scaling approach. Especially when existing one is named so generic. My original inkling was to name it scoped const or sconst, since that's what the proposal was originally named. The idea to use inout was because of the allergic reaction all the maintainers had at the time to adding any new keywords -- inout was fully superseded by ref, and technically "available" without introducing any new keywords. I almost wish we had never named it that, but I was too happy to have the feature at the time. I think it wouldn't be a bad idea to investigate a new way to express attributes, but I think no matter what we do, we need to rein in the explosion of attributes that needs to be put on every function. -Steve
Re: http://wiki.dlang.org/DIP25
On Monday, 29 December 2014 at 21:29:21 UTC, Steven Schveighoffer
wrote:
I think it wouldn't be a bad idea to investigate a new way to
express attributes, but I think no matter what we do, we need
to rein in the explosion of attributes that needs to be put on
every function.
For that I think attribute inference is the way to go - though in
a bit more structured fashion than it was originally proposed
ages ago ("just infer everything")
Re: Worst Phobos documentation evar!
On Monday, 29 December 2014 at 19:47:50 UTC, Walter Bright wrote: On 12/29/2014 3:19 AM, Jacob Carlborg wrote: On 2014-12-29 06:39, Walter Bright wrote: Having used both Ddoc and Markdown, I seriously disagree with this. Take a look at the markdown source for DIP69. It's horrific. Do you mean on the wiki? The wiki doesn't use Markdown. At least not anyone I've seen. It uses something pretty similar. They all kinda mush together in my mind :-( It's NOT SIMILAR at all. It's a completely different language. Also as mentioned above, DDoc macros are extremely ugly and hard to read (and to make sense of, with their lisp-ness). Not to mention, *almost everyone* coding today knows Markdown and can immediately begin contributing to the docs, without looking up DDoc documentation or a *freaking macro file in one of D's repositories*. Only a subset of D devs know DDoc macros, and a very small minority of those know DDoc macros used by Phobos. This is ugly, it is the *very definition* of ugly. (how the heck am I even supposed to read that?): DDoc: $(OL $(LI If $(D line) has type $(D string), $(D wstring), or $(D dstring), a new string of the respective type is allocated every read.) $(LI If $(D line) has type $(D char[]), $(D wchar[]), $(D dchar[]), the line's content will be reused (overwritten) across reads.) $(LI If $(D line) has type $(D immutable(ubyte)[]), the behavior is similar to case (1), except that no UTF checking is attempted upon input.) $(LI If $(D line) has type $(D ubyte[]), the behavior is similar to case (2), except that no UTF checking is attempted upon input.)) This is *much less ugly*: Markdown: 1. If `line` has type `string`, `wstring`, or `dstring`, a new string of the respective type is allocated every read. 2. If `line` has type `char[]`, `wchar[]`, `dchar[]`, the line's content will be reused (overwritten) across reads. 3. If `line` has type `immutable(ubyte)[]`, the behavior is similar to case (1), except that no UTF checking is attempted upon input. 4. If `line` has type `ubyte[]`, the behavior is similar to case (2), except that no UTF checking is attempted upon input. And my favorite, tables in DDoc. First 3 lines for brevity: DDoc: $(BOOKTABLE Cheat Sheet, $(TR $(TH Function Name) $(TH Description) ) $(LEADINGROW Searching ) $(TR $(TDNW $(LREF all)) $(TD $(D all!"a > 0"([1, 2, 3, 4])) returns $(D true) because all elements are positive) ) $(TR $(TDNW $(LREF any)) $(TD $(D any!"a > 0"([1, 2, -3, -4])) returns $(D true) because at least one element is positive) ) ... Markdown (assuming some kind of automatic crossreferencing, which *needs* to be in any decent documentation generator, and DDox, which renders your "preview new" documentation, already does it) | Function Name | Description | | - |- | | #all | `all!"a > 0"([1, 2, 3, 4])` returns `true` ... | | #any | `any!"a > 0"([1, 2, -3, -4])` returns `true` ... | (shortened to fit mail, but you should be able to get the point) If you don't want so many pipes / aligning work, this works too: Function Name | Description - | - #all | `all!"a > 0"([1, 2, 3, 4])` returns `true` ... #any | `any!"a > 0"([1, 2, -3, -4])` returns `true` ... And yes, the above is limited, it can't do everything DDoc can do. Macros are useful when you need something way out of the ordinary. But using them for things like tables or lists or 5 different macros for links because you don't think cross-referencing is important is insane. I'd be happy if I could use *something that's not DDoc macros* 99% of the time. But if I want my docs to be anything better than bare text with Params:, Returns: and Examples:, I have to write that kind of gibberish (actually, not anymore, as I said I'm working on DDoc + markdown).
Re: Worst Phobos documentation evar!
Great, width limit messed up the (first version of) the table. | Function Name | Description | | - |- | | #all | `all!"a > 0"([1, 2, 3, 4])` returns `true` | | #any | `any!"a > 0"([1, 2, -3, -4])` returns `true` |
Re: Worst Phobos documentation evar!
On Monday, 29 December 2014 at 21:23:07 UTC, ketmar via Digitalmars-d wrote: On Mon, 29 Dec 2014 21:10:15 + bachmeier via Digitalmars-d wrote: That's not something we should assume a new D user will know. Someone with a few years of C++ experience will probably be okay, but that's kind of my point - the documentation shouldn't require that background. I can imagine someone seeing examples that use auto with ranges and then asking "Now what?" Those are the frustrations that make users give up on the language. trying to use the language one didn't even bother to learn will inevitably lead to frustration. first time i tried to use Forth was... painful. but it was Z80 machine and i have no other sane choices, so now i love Forth. The only reason to read documentation is to learn the language. Based on the responses to my post, it's becoming clear why D has a reputation for terrible documentation...
Re: Worst Phobos documentation evar!
On Mon, Dec 29, 2014 at 09:10:15PM +, bachmeier via Digitalmars-d wrote: > On Monday, 29 December 2014 at 17:38:42 UTC, H. S. Teoh via Digitalmars-d > wrote: > >Most Phobos range functions return opaque types that the user should > >not depend on (even if the type is nameable), since the point of the > >range API is to have user code Just Work(tm) without needing to know > >the actual type of the returned object. > > That's not something we should assume a new D user will know. Someone > with a few years of C++ experience will probably be okay, but that's > kind of my point - the documentation shouldn't require that > background. I can imagine someone seeing examples that use auto with > ranges and then asking "Now what?" Those are the frustrations that > make users give up on the language. You're missing the point. The user *should not* know what the returned type is! (And cannot know, when it's a local struct inside the function that has no name outside.) The type is *intentionally* opaque, because the whole point of using such a construct is to prevent user code from having explicit dependencies on the actual type. Explicitly documenting the precise type defeats the purpose completely, and we might as well go back to C and use ExplicitIterator*, AnotherExplicitIterator*, YetAnotherExplicitIterator*, with 150 different structs defining 150 functionally-equivalent things that only just happen to be implemented differently. Of course, the flip side of that, is that probably all references to range return types (or any other Voldemort / opaque return types, for that matter) should to hyperlink to an explanation for what kind of operations the returned type supports. I don't think the issue you bring up will be a problem if the function documentation says something along the lines of: Returns: A [forward range] of integers. where [forward range] is a hyperlink to a definition of what a forward range is and what it does. In fact, here's another low-hanging fruit for wanna-be Phobos contributors: add said hyperlinks to all the range-based functions in Phobos. Or, better yet, since these things are so common in Phobos, add a macro that contains the hyperlink for each type of range, and just write $(INPUT_RANGE), $(FORWARD_RANGE), etc., instead in all places in the documentation where it occurs. T -- PNP = Plug 'N' Pray
Re: Worst Phobos documentation evar!
DDOC is probably one of D features with pretty idea and hardly usable design. I wish we had something like Markdown instead - can never remember Phobos macros to use and usually just resort to using plain text instead.
Re: Documenting parameters [was: Re: Worst Phobos documentation evar!]
On 12/29/2014 11:58 AM, Adam D. Ruppe wrote: On Monday, 29 December 2014 at 19:51:26 UTC, Walter Bright wrote: The current defaults make it work without needing a style sheet. That's pretty much the reason why they are the way they are. You could also just bundle a stylesheet with it, which would be the best of both worlds. Have the semantic tags in the main macros and the style as an embedded
Re: Worst Phobos documentation evar!
On Mon, 29 Dec 2014 22:12:59 + bachmeier via Digitalmars-d wrote: > The only reason to read documentation is to learn the language. O_O signature.asc Description: PGP signature
