immutable
Hello,
I have just recently started programming in D (a very pleasant experience so
far I must say), but when experimenting with the the immutable attribute I
discovered that the following code does not generate a compile time nor a
runtime error:
//Decalare immutable string
immutable char[] buf = "hello";
//Print the value of buf
writefln("buf = %s",buf);
//Change buf by using standard input
stdin.readln(buf);
//Print buf again
writefln("buf = %s",buf);
This is a bit confusing to be because I had assumed that immutable data really
would be immutable (without casting). Why does the code above work?
Cheers
Nilew
Re: immutable
I didn't expect the code to run, hence my question. I tried it on OSX first which might have been the reason. Ran it on Ubuntu too and got the expected segmentation fault. But thank you for the answer, I have filed the bug. Robert
Re: immutable
Hopefully they will give it double the attention then ;)
On D development
When reading stuff, like: "Yes this is bad, but people use it already, so we could only possible change this in D3 or something" and reading endless discussions about a new feature (e.g. ref semantics) of how it could break things and so on, I thought it might be a good idea to implement new features in an experimental version, which can then be thoroughly tested and only if nothing bad found they will be merged in the stable branch. People simply have to be aware that they should not rely on semantics implemented in experimental. Discussions about new features before their are implemented would of course still be a very good idea, but it would reduce the pressure a bit, because you can simply try. This does not solve everything, because some issues will only pop up if used for a long time or only in real complicated production code, but I think it is better than the approach of having no way back? I don't believe this idea is entirely new or maybe I am missing something. What do you think? Best regards, Robert
Re: [OT] D mentioned in Channel 9 TypeScript/Dart interview
It is mentioned that the D forums are written in D. I wasn't aware of that. May I ask how? Is vibe being used? Or from scratch, is there any source code available? Thanks! Best regards, Robert On Sat, 2012-11-03 at 19:49 +0100, David Nadlinger wrote: > On Saturday, 3 November 2012 at 18:18:50 UTC, Andrej Mitrovic > wrote: > > I'm almost sure Charles interviewed Walter and Andrei once, it > > was on > > video somewhere. > > Yes, he did: > http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-6-The-D-Episode-with-Walter-Bright-and-Andrei-Alexandrescu > > David
std.signals2 proposal
Hi there!
I just developed a proof-of-concept implementation of an improved
std.signals.
Things I did not like about the current implementation:
1. Passing a delegate to connect, which basically is an extended (void*)
and assuming it is an object delegate, does not feel quite right in D,
where we usually try to guarantee correctness by the compiler wherever
possible.
2. The restriction that only objects can be connected.
Point 2 does not really bother me, because from my little experience I
never really had connected anything else than objects to a signal. But
the restriction that the connected delegate must not be some wrapper, is
quite a restriction I came to dislike about Qt and even more so with
this implementation because unlike Qt the signatures have to match
exactly, you can't omit parameters, like:
// Qt code
connect(button, SIGNAL(clicked(bool)), this, SLOT(buttonClicked());
-> In the current implementation buttonClicked would have to take a
bool.
In addition boost::signals together with boost::bind offered even more
comfort like passing additional parameters to a slot, which is really
very, very useful:
for(int i=0; ihttps://github.com/eskimor/phobos/tree/new_signal
You can easily connect to an object's method with:
obj.signal.connect!"someMethod"(obj);
instead of the old implementation:
obj.signal.connect(&obj.someMethod);
-> The interface is clean and type safe, all the ugly details are hidden
from the user. And it is just one character more typing. Simple things
stay simple.
In addition a method allowing wrapper delegates was added:
class Observer {
void addNumber(int i) {
sum+=i;
}
int sum;
}
class Button {
Signal!(bool) clicked;
// ...
}
void main() {
auto b=new Button;
auto o=new Observer;
// Ignore boolean parameter and pass some int:
b.connect!Observer(o, (o, p) { o.addNumber(7); });
// or even:
b.connect!Observer(o, (o, p) => o.addNumber(7));
// For some reason the compiler is not able to deduce "o" being
// Observer, so the !Observer is needed, but it is still very
// neat and readable.
}
Thanks to D's lamdas the syntax is even more concise as boost::bind and
far more powerful.
By passing the object explicitly to the delegate, it is possible to
maintain the 'weak ref' semantics to the target object, while ensuring
that the delegates context won't be freed.
As a side effect it is now even possible to use struct delegates or even
any non object delegate. Simply pass null for the obj parameter. It is
completely safe, the only drawback is that the struct won't be deleted
until the Button gets destroyed. (Because it holds a reference to the
struct, by means of the delegate.) But for long lived structs this
usually is perfectly acceptable.
Implementation:
In my implementation I changed the Signal mixin to be a simple template
struct, because I hit strange compiler errors with it being a mixin. The
most prominent:
std/signals.d(443): Error: no overload matches for connect(string
method,T2) if (is(T2 : Object))
You can find the version triggering these errors at:
https://github.com/eskimor/phobos/tree/new_signal_mixin
Also I did not really get the point why a mixin was used in the first
place, it does not really gain us anything? What was the reasoning about
it?
I almost thought I found the reason, because my implementations suffers
from unhook not being called, although it was properly registered with
"rt_attachDisposeEvent(obj, &unhook);", thus causing a segmentation
fault when the observer gets deleted. I did not really find any
difference from the original version that could explain this behavior,
despite the original implementation being a mixin. So I thought, well
maybe the delegate passed to "rt_attachDisposeEvent(obj, &unhook);" must
be an object delegate (that's would be why the mixin was needed), but
after digging in object_.d I did not find any code assuming that the
delegate was an object delegate. Any ideas on this?
Another thing I'd like to ask Walter, is what the "L1:" label is for in
connect(), is it just some left over or has it some special internal
compiler thing meaning?
What do you think?
Best regards,
Robert
Re: std.signals2 proposal
Thought so. Thank you! > Presumably, it's left over from > some previous refactoring. > > - Jonathan M Davis
Re: std.signals2 proposal
> Hi!Could you write some examples for struct and non-object
> delegates?
>
Sure!
Something like:
struct Observer {
void observe(int a, int b) {
// ...
}
}
void main() {
Signal!(int, int) s1;
Signal!int s2
Observer o;
s1.connect!Object(null, (null_object, a, b) => o.observe(a, b));
s2.connect!Object(null, (null_object, a) => o.observe(7, a));
}
Having the delegate accept a null parameter might not be pretty, but I
consider this a good thing, because of the changed semantics: The signal
will keep a reference to the struct now, so the signals weak reference
semantics are no longer in place. (If struct is allocated on the heap,
it won't be freed as long as the signal is alive.)
But it is possible and safe. And if you know what you are doing also
very reasonable.
But the main benefit is not that you can connect to structs (which is a
side effect), but that you can use wrapping delegates which do parameter
adoptions. That's the killer feature that proved to be so indispensable
and neat for me and others.
If really required it would not be to hard to provide an overload of
connect() which takes a struct pointer directly, just like the one
taking an object, but because of the changed semantics and the rare uses
I'd expect, probably not worthwhile. But comments are appreciated.
Re: Binary compatibility on Linux
I would say supporting distributions which are no longer supported by the distributions itself is of very little value. So for Ubuntu the last still supported LTS version should be old enough. I think virtually nobody is using anything older, especially not 06.XX! And if they do, then they will have a whole bunch of other problems than not being able to use your program. Best regards, Robert On Sat, 2012-11-10 at 20:01 +0100, Jacob Carlborg wrote: > On 2012-11-10 19:49, Jordi Sayol wrote: > > > Ubuntu 10.04.4 LTS is old enough? > > I have no idea. I don't know how often people update their Linux systems > and how compatible different distributions are. Sine I'm not using Linux > as my primary platform I was hoping someone else could answer this. > > What is the oldest system I need to reasonably support? I'm mostly > talking about tools and libraries for the D community here. >
Re: std.signals2 proposal
On Fri, 2012-11-09 at 19:28 +0100, Kagamin wrote: Huh? I don't get it. Didn't you want weak ref semantics for > signals? Why do you want strong ref semantics now? > There is a distinction between the context of a delegate, which is used for parameter transformation or other advanced stuff and the final destination object. The first one is very likely that only the signal has a reference to it (think of lamdas), and thus the signal holds a strong ref to it. For the object, which method gets eventually invoked, the signal does not hold a strong ref, instead it simply drops the slot when the object gets deleted. In your example, to make it work with weak ref semantics with the new signal implementation: _tab.closed.connect(this, (obj, sender,args)=>obj.Dispose()); instead of: _tab.closed.connect((sender,args)=>this.Dispose()); (obj, sender,args)=>obj.Dispose() is in this case just a function or a delegate with null ptr as context. But if there were a context the signal would keep it in memory. The object which gets explicitly passed to the delegate via obj, is only weakly referenced from the signal. The whole purpose is to make indirect connections to an objects method possible, for parameter transformations, parameter omissions, for providing additional parameters, ... If you want a direct connection you would use the simpler: signal.connect!"Dispose"(this); as explained in my initial post.
std.signals2 status
Hi there! My std.signals2 implementation is already in quite a good shape and feature complete, improvements over std.signals: - safe connect method to an object's method (weak ref semantic) - support for indirect connect to an object's method via a wrapper delegate (weak ref semantics to target object) - strongConnect method for connecting to non objects. (strong ref semantics) - disconnect method for disconnecting all methods of a given object with a single call. - Proper exception handling. Meaning if a slot throws an exception the other slots will still be called and all slot exceptions are chained together. - signals methods are safe to call from within a slot. (For disconnecting, and even for emit() and stuff, which is useful if you think of fibers.) This is not yet tested, but it should work. - signal copying is forbidden, as it can not be made to work with D's relocatable structs. (Current std.signals triggers a segfault) - Signals are implemented as structs *) instead of a mixin and every template parameter agnostic code also does not depend on the template parameters -> avoid template bloat. - Memory footprint for empty signal is even lower than the one of the current std.signals, which is important because many signals end up not being used at all. - Provided mixin wrapper which allows only the containing class to issue emit(), but everyone to connect. - Memory allocations are kept to a minimum necessary Todo: - Update documentation - Write more unittests - Rename to std.signals2 Code can be found at: https://github.com/eskimor/phobos/blob/new_signal/std/signals.d (will be renamed to signals2.d eventually) There is just one thing in the way: http://d.puremagic.com/issues/show_bug.cgi?id=8441 Because of this, my current mixin wrapper does not compile, it seems to be somewhat related to: http://d.puremagic.com/issues/show_bug.cgi?id=9053 but I am not sure. If someone out there with compiler writing experience wants to have my super cool std.signals2 in phobos, you might wanna have a look at this issue. On the other hand I could use some string mixin, but I think the result would be less nice, nevertheless I am open for suggestions. The result should be, that it is just one line of code to have a signal in your class which only the implementation of the class (ok in D the containing module) can emit, but everyone can connect to. Thanks for any suggestions or fixes :-) Best regards, Robert *) A signal is implemented as a struct, so it is an entity on its own which can be referred to. This can be useful for things like connection managers, where you can pass signals to them and they take care of connecting slots to all of them, ...
Re: Errors compiling DSSS
> > On 2012-11-27 08:13, Gor Gyolchanyan wrote: > I'd recommend RDMD. It can compile (and run) > the given module and it's > entire import tree. No build scripts are > necessary. > Very convenient with pragma(lib, "...") Btw. if you you use rdmd via sha-bang, there is no way of passing any compiler flags in the #! line (because only a single arg is supported: http://en.wikipedia.org/wiki/Shebang_%28Unix%29 Is there any way of adding compiler flags like -I paths or something in the source file for rdmd? Much like pragma(lib, "")? This would be really useful for "scripts" that need more than just the standard library. Thanks! Best regards, Robert
Re: Errors compiling DSSS
> #!/usr/bin/rdmd > /**rdmdoptions > -L-lmylib > */ > ... > > What would be some useful options to add, aside from those already > supported? > Providing arbitrary compiler flags would already be a huge gain. So one can pass libs, -I include paths, ...
Re: Errors compiling DSSS
On Tue, 2012-11-27 at 10:51 -0500, Andrei Alexandrescu wrote: > Thats why I included the --shebang flag in rdmd. > > Thanks a lot! That is very very nice. I wasn't aware of this because I relied on the very outdated man page, instead on rdmd -h. Wow rdmd is far more powerful now :-)
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
> Is there absolutely no concern for D users's code? It certainly > seems like it. Maybe it would have made sense a decade ago when D > was just starting... but D has been around for over 11 years now. > To have screwed up so badly that after 11 years you still don't > have a stable platform to write code for (well, you do with D1, > but in a month there will not be that excuse) is mind boggling. I tend to disagree a bit. First D is a very, very powerful language written by just a few people, with no commercial background, so I think it is quite reasonable that it takes more time to stabilize than much simpler languages, let's say python. I also in general think, that fixing things is a good idea, even if breaking code, but it is really annoying if your code breaks, especially if you can not easily find the reason. For this reason and others (more testing) I would also very much appreciate (I already suggested this before) to have a stable branch, that really only receives bug fixes and a new major version release every half a year or so (given D's speed of development). It should not be too frequent, because it will be a lot of work: 1. Document precisely any breaking changes for the new version + a recommend way of updating (which was tested). 2. Provide tools that fix your code automatically. Wherever reasonable & possible. Because I think, the least you can do is to have a thorough discussion somewhere of what breaks and how to fix it. I would be very much less pissed by breaking changes, if I could at least look them up quickly and get a solution for it. For point 2, we would start with some easy tools like search and replace (for name changes and such) and improve them over time to parse context, ... (e.g. like http://coccinelle.lip6.fr/sp.php ) -> The easier and automated the upgrade path, the better. Old version could be supported until the major version after the next one comes out. Encourage people to upgrade early and make it as easy as possible for them. Are breaking changes of any kind documented somewhere at the moment? The release model I have in mind: 1. Every few months a new minor release for both the unstable and the stable version. (To get early and good testing for the unstable version & to find out any unexpected breakings) 2. Every six/eight/twelve months: The current unstable will become the new stable with all breakings perfectly documented & uprade scripts written. If it is too much work to support two stable versions, we could drop updates as soon as a new version comes out. Breaking changes should still be avoided of course, but if needed they should be possible. Best regards, Robert
Re: D Stable Proposal
My github account is eskimor. I think the model described in: http://nvie.com/posts/a-successful-git-branching-model/ is a really good one, to get started. If we want to keep changes to a minimum, then the development branch in the model could simply be the current master. The master branch in the model would be the master branch of dmd-stable. Feature branches already exist in form of pull requests. Release/hotfix branches would have to be introduced. A little education of people would be needed. (E.g. where and when to merge things, bugs/features.) Where and how changes are documented. I would volunteer to help writing an automatic upgrade tool. We should, define things there, so reports of breaking changes/deprecations, the developers provide, could then be already in a format the tool can understand. On Thu, 2012-11-29 at 23:49 -0600, 1100110 wrote: > On 11/29/2012 11:17 PM, Rob T wrote: > > On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote: > >> Let's do this thing. > > > > I can help with formulating a process and I can also help write up the > > guidelines and so forth, so I'll sign up. > > > > If we can decide on a road map and write it up, and get enough consensus > > for implementing it, then everyone will know what they should be working > > on, and also what to expect. > > > > How many people do you think we need to get started, 5 or so? > > > > --rt > > > > I've started work on the specification here > https://github.com/D-Programming-Language-Stable/dmd/wiki/Specification > > I'd like for someone else to start with the writeup, since I've pretty > much made my ideal known by this point. > > If you have a github account, give me your user name and I'll add you to > the Project. > > It'll at least give us a public place to define things for right now.
Re: D Stable Proposal
On Fri, 2012-11-30 at 07:31 +0100, Rob T wrote: > One quick suggestion before I call it a day, is for there to be > an "experimental branch" for the great minds behind D to play > around with (eg UDA's etc). We probably don't want experimental > stuff going directly into a branch that is destined for stable. > Unstable should be for items that are relatively finalized in > terms of design and agreement that the concept is to be > eventually incorporated into stable, i.e., moving a new feature > into unstable starts the refinement process towards a stable > release of that feature. Totally agreed. In the development branch only already finalized things should be merged. Having official experimental branch(es) is a good idea. I think the things people are working on should be easily accessible. So other people can contribute and test the stuff. These branches should then also be included in dpaste.dzfl.pl. Maybe a dmd-experimental project, where people can get access to, very easily. So they can push their branches there. It should be as easy for people to try out experimental things as to try out things from the development branch, to get as much early testing as possible. Automatic creation of binary releases would also be cool. So the workflow could be something like: 1. Document on a dedicated wiki page that you start working on feature X or bug fix Y. 2. Get started on a private/semipublic feature branch. 3. As soon as you got something push it to dmd-experimental 4. Continue to work and improve things there 5. Experimental branches are considered for inclusion in devel. 6. Things are tested in an integrated way in devel, with binary releases every two months or so. (Much like we have now) 7. At predefined intervals you branch of a release branch and stabilize things further. 8. Release branch is merged in dmd-stable/master Someone posted this, as why not to use feature branches: http://www.youtube.com/watch?v=xzstASOvqNc&feature=youtu.be I personally don't think that feature branches are the problem, but more a lack of communication. If people work on the same stuff you get merge conflicts, that is granted, so you should know on what people are working before starting to work. A wiki page where you add a link to your feature branch and what you are currently working on and dmd-experimental could help in this regard.
Re: D Stable Proposal
On Fri, 2012-11-30 at 06:02 -0600, 1100110 wrote: > I have just been reading that for advice and find the --no-ff > comments > confusing. Can you explain that please? I see two contradicting > claims. > > Well the comments say that --no-ff does not create a single commit of the merged in commits, but only create a merge commit. Which is right, but it suffices to preserve the merge information and what was merged. In a fast forward merge basically the following happens: ---**-*-*master You branch to my_branch and do a commit ---**-*-*master |*mybranch If you merge mybranch into master now: ---**-*-**master/mybranch The information is now lost that the last commit actually came from mybranch, with --no-ff you get a merge commit, which is special because it has two parents: git merge --no-ff mybranch: ---**-*-* * master |/ |*mybranch You can now list the commits that came from mybranch with the following command: git log master^..master^2 or simply visually print the merge graph in the log messages: git log --graph
fedora 18
Installing the rpm of dmd-2.061 under Fedora 18 fails for me. Via package-kit I get an error that it is unsigned, via yum I get the following errors: Transaction Check Error: file / from install of dmd-2.061-0.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/bin from install of dmd-2.061-0.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/lib from install of dmd-2.061-0.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/lib64 from install of dmd-2.061-0.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 Error Summary Has this anything to do with the new rpm version used in Fedora 18? Is anyone else having problems? Best regards, Robert
Re: std.signals and malloc
Of course. Just at the moment issue: http://d.puremagic.com/issues/show_bug.cgi?id=8441 is holding it back. It will be probably named std.signals2 or something to maintain backwards compatibility, but yeah I definitely want to get it into phobos. In fact, I don't even have a use for it in my own projects, I just saw the current implementation and thought there must be a better way. So the whole point of implementing it, was to get it into phobos. I strongly encourage you to use my implementation, because real world testing before becoming a part of the standard library is always a good idea. But keep in mind, that it wasn't formally reviewed yet so your code might break, when being included into phobos. (Stuff might get renamed for example.) On the other hand fixing this issues should not be too much work. So yeah, please try it out, so it will be perfect when included. The feature set and set of improvements, should be convincing anyway, if not I have done something wrong. As said before, you will have to remove the template mixin at the beginning, (because of the above mentioned bug) and use the struct FullSignal directly. The split up in FullSignal and RestrictedSignal, was to be able to disallow others from emitting the signal. I would be glad to answer any questions about its use and improve documentation where necessary. Best regards, Robert On Sat, 2013-01-19 at 22:47 +0100, David wrote: > Am 19.01.2013 19:39, schrieb eskimo: > > The new implementation offers this possibility, with the strongConnect() > > method. The old implementation wasn't able to do so, because a delegate > > contains no type information about the context. > > > Any plans of getting this into Phobos as a std.signals replacement? > Otherwise using it doesn't make too much sense. (a class is the lesser > of the two evils)
Re: Trust about D programming.
Well I could name slicing and meta programming (templates, traits, mixins). But in reality it is more the feel of the language. It is easy to read, (in D I even understand programs written by other people!), it is powerful. Due to its meta programming techniques it has much of the power typically only found in dynamically typed languages, but with the safety and speed of compiled, statically typed language. Typically when a language becomes powerful, it also becomes complex and hard to learn, I think D did a really good job in being one of the most powerful languages out there but still being "easy" to learn and understand, in particular easy to read. The concepts are sound and well thought of. It is fun to use it. The down side is, that it is far less mature than C or C++. One of the things that convinced me, was slices and the way the GC is put to good use. Things that make me stick to it, are the meta programming capabilities, its power and its design. Best regards, Robert On Tue, 2013-01-22 at 12:17 +0100, MMj wrote: > On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote: > > On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote: > >> Hello Folks. > >> How are you? > >> Excuse me, I need a trust about D programming and C, In your > >> opinion D can be a replace for C? > >> Why a user should use D? > >> Please let me know your opinion. > >> > >> Thank you. > >> Cheers. > > > > It really depend on what you try to achieve. But in many case > > it is a viable alternative. In other, things need to be ironed > > out. > > I saw D wiki and understand some goals about but Can you tell me > why you choose D and not C?
Re: D popularity
Wow! :-) Thanks for this link. This is so much better! :-) Best regards, Robert > > Check out the new experimental on-line documentation. > http://vibed.org/temp/d-programming-language.org/phobos/std/range.html > > You can put in user comments too. > > Still not as good as it can be, but it's a big improvement over > the existing documentation. > > The important thing is that D seems to always be improving, and > the community is very active. > > --rt
Re: @property - take it behind the woodshed and shoot it?
Apart from +=, ++, what breaks compatibility of fields and properties,
is that you can't take the address of a property, but of a field (as
already mentioned). To increase compatibility and in order to avoid
breaking peoples' code, when a field is changed to a property, maybe,
simply offer the possibility to declare fields to be a property too,
with @property. And make it so that the access to such a field behaves
exactly the same as to a property: No address taking, and as long as
properties don't support ++, +=, ... maybe even forbid those.
Example:
@property int a;
would be completely equivalent to:
int a_;
@property int a() {
return a_;
}
@property int a(int new_a) {
a_=new_a;
return a_;
}
I think this would suffice to make the property concept really sound and
working in practice.
If, this is considered a good thing, I could create yet another property
DIP.
Another thing I am wondering, will this still be possible:
void myProperty(int a) @property {}
void function(int) dg=&myProperty;
Or in other words, will taking the address of a property method still be
possible? I think it would be quite sensible and useful (for e.g.
std.signals), taking the address of a transient return value does not
make any sense anyway, so no ambiguity here. On the other hand it would
break compatibility with fields again. So if we also want to make sure
the way back (from property methods to field) works, disallowing taking
the address might be the way to go for a finally proper implementation.
To the C# experts: How does C# solve those two issues?
Best regards,
Robert
Re: @property - take it behind the woodshed and shoot it?
Proper property design:
>
> @property int a;
>
gets actually lowered by the compiler to:
>
> int a_;
>
> @property int a() {
> return a_;
> }
> @property int a(int new_a) {
> a_=new_a;
> return a_;
> }
>
-> field property, and get/set property are actually the same thing. ->
It is guaranteed that they behave the same way and can always be
exchanged.
-> Taking the address of the getter/setter also always works, enabling
things like connecting the setter to a signal for example.
I don't know about you guys, but I love this. It is just perfect. What
do I miss?
Best regards,
Robert
Re: @property - take it behind the woodshed and shoot it?
Yeah, I thought of that and the compiler can optimize it away if not needed. So this would be fine, but see my second, improved proposal. On Thu, 2013-01-24 at 23:37 +0100, Adam D. Ruppe wrote: > Indeed, but there's an easy alternative too that works with both > kinds of data, properties and regular: wrapping it in an function > at the usage site, e.g. "(a) => myProp = a;"
Re: @property - take it behind the woodshed and shoot it?
There is, just don't do:
@property int a;
but
int a_;
@property int a() { return a_}
-> Omitting the setter. It is a bit more verbose than the C# version,
but adding syntactic sugar later on, if really desired, should not be
too hard.
And thanks for the C# implementation description.
On Thu, 2013-01-24 at 14:48 -0800, Adam Wilson wrote:
> The syntax provides no way to define read-only or write-only
> properties.
> Other than that I love it, but I am a biased C# guy.
Re: @property needed or not needed?
@property use:
I'd like to point out, that regardless of the "with parens/without
parens" stuff, marking properties with @property makes sense. So that
tools and frameworks can recognize them as such. This also implies that
fields that are meant as properties should be declared @property and the
compiler should generate getter/setter so it behaves exactly like a
manually created property. May I add this to DIP21?
Having the compiler lower the following:
@property int a;
to
private int __a;
@property int a() {
return __a;
}
@property int a(int new_a) {
__a=new_a;
return __a;
}
would make properties and property declared fields really exchangeable,
namely you can no longer take the reference of an @property field, just
like you can't take the address of a property with get/set.
Best regards,
Robert
On Sun, 2013-01-27 at 22:24 -0500, Steven Schveighoffer wrote:
> On Sat, 01 Dec 2012 20:03:21 -0500, Jonathan M Davis
> wrote:
>
> > I'd _love_ to make it illegal to call non-property functions without
> > parens,
> > and there are definitely folks around here who agree with me, including
> > some on
> > the Phobos dev team (e.g. Steven has always agreed with me when this has
> > come
> > up), but there are enough folks around here here who like to call
> > functions
> > without parens - especially with UFCS and templated functions like map or
> > filter - that I don't think that that's going to fly at this point.
>
> Oh, shit. I missed another important @property discussion.
>
> OK, I will say my peace:
>
> The issue I have with not implementing this is takes power away from the
> designer.
>
> There are three intentions when creating a function w/ regards to
> properties:
>
> 1. You intend the function to be called without parentheses to clarify it
> is a property.
> 2. You intend the function to be only called with parentheses to clarify
> it is a function.
> 3. You don't care whether it's called with parentheses or not, because the
> name of the function is clearly a property or a function.
>
> These distinctions are important because of the human meaning of the
> function. i.e. x.read() vs. x.read. The former looks to me like "read
> using x", the latter looks like "is x read."
>
> With @property, the idea was to implement 1 and 2, and leave nothing for
> poor #3. It's this #3 which throws a big fat wrench into my evil plans.
> Things like map or filter, which clearly aren't properties by their
> name/usage.
>
> I had a compromise that void parameterless functions could be
> unambiguously called without parentheses. For example, if x.read()
> doesn't return a value, then the statement:
>
> x.read;
>
> Can't really be misinterpreted as "is x read" because the code isn't using
> the (implied) result.
>
> So that is why I always thought, make non-property functions require
> parentheses.
>
> But here we are almost 4? years later and still have the same situation.
> I give. As long as we can't call arbitrary functions as setters, I think
> the other failures of allowing the choice of removing parentheses are far
> less severe. At least we get #1.
>
> The proposed DIP does not look bad, I say do it.
>
> -Steve
Re: @property needed or not needed?
They don't. If you want such behaviour, you would write your own setter getter, with @property attribute, just like you do now. Best regards, Robert On Mon, 2013-01-28 at 15:00 +0100, Maxim Fomin wrote: > Besides, how such implicitly defined > functions may call user defined code (check input validity, call > events, etc.)?
Re: Expanding Phobos from a flat hierachy
On Wed, 2013-02-06 at 08:56 +0100, Don wrote: > Eg, are there entire top-level branches which are obsolete? How > many stupid names are there (eg, "std.algorithm2") which were Well in order to avoid such "stupid" names, I think it would be a good idea to keep the standard library small. Include only the things that are important to be "standard" in order to ensure interoperability between libraries. Instead we should offer a central place for D libraries, like CPAN for perl or http://pypi.python.org/pypi for python. The benefits: - The base installation stays small, which might be important for everything that is not a PC. - Versioning is easier, because every library can exist in multiple versions, and every project can choose to which version it wants to link. (For backwards compatiblity) -> No stupid names, if the libraries are small, simply deprecate the complete library. -> In fact such a central place is already on my todo list. I have the idea of creating an infrastructure, where you can easily write D scripts, which may import arbitrary libraries from the repository. A tool like rdmd would then notice that the libraries are not installed locally, so it does install them before running the script. (I think of integration with http://openbuildservice.org/ for Linux based systems and some custom installer for Windows.) -> This way we would have a really convenient way for scripting in D and it would be easy to toy around with an idea, before creating an actual project. -> So instead of creating a single monster standard library, just offer a central place for D libraries and automatic dependency management. I hope that I find the time soon to implement such a thing, but it will be a huge amount of work and maybe this is the right occasion to ask, whether anyone else thinks this would be a good idea. Just some of my recent thoughts. Best regards, Robert
Re: Expanding Phobos from a flat hierachy
On Wed, 2013-02-06 at 14:42 +0100, Jacob Carlborg wrote: > Here you go: > > https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D :-) That is pretty much what I had in mind! Awesome! I would love to help with this. I would start with some writing down of my ideas and concepts I have in mind, if you are interested? If you are, where should we discuss such things? On this mailing list? > > I will replace the Ruby code with D. As the ultimate goal of my idea was to establish D as a compiled language with all/most of the benefits of interpreted languages, it would seem strange if the tool that made this possible was not written in D. It would suggest that this was not possible in the first place. So I think this is a good idea. Concise definitions could be made possible, either by importing stuff in an appropriate environment as Andrei suggested or if needed even via a DSL, with string mixin's. So I think D already offers all we need, for good concise configuration files? Best regards, Robert
make @safe "non-escapable"?
Making the following code illegal:
import std.stdio;
@safe {
int test1() @system {
int* p=new int;
*p++=8;
return 7;
}
}
So if you mark code with @safe you can not mark parts of it to be
@system. This would make things possible like compile time import of
configurations, which would currently impossible in a safe way.
For importing the config file you would simply do:
@safe {
mixin(import("app.cfg"));
}
Guaranteeing that the code in app.cfg has to be safe.
I thought of some wrapper like safeImport() which searches the code for
@system or @trusted and rejects the code if one of them is found. But
this is quite hard to do it right, especially with mixin's. So it's
probably best if the compiler handles this.
What do you think. Should I file a bug report?
Best regards,
Robert
Re: Expanding Phobos from a flat hierachy
+1 from me. As long as we don't have a central repository, where we could have a separate phobos-staging package or something. At the moment I don't think that additions to phobos were tested much in real world before being adopted. Such an experimental section could really help and we should try to get things in there quickly, to boost the whole process a bit. Best regards, Robert On Wed, 2013-02-06 at 19:47 +0100, Brad Anderson wrote: > I really like the idea of an experimental section of phobos. I've > been thinking lately that the phobos review might be improved by > doing something more like this: > > 1. Proposal > 2. Review and vote of overall usefulness and whether it meets a > certain quality requirement. > 3. Module is placed in experimental section of phobos with strong > warnings that it is a trial module and could be removed in a > future update. > 4. Following a set period of time after the module has been in a > public release another vote is held for actual inclusion. > 5. If yea, move to its final resting place, if nay remove it for > the experimental section.
Re: make @safe "non-escapable"?
Done: http://d.puremagic.com/issues/show_bug.cgi?id=9463 Best regards, Robert > > > > What do you think. Should I file a bug report? > > > > Yup. >
On DIP 23
Well first what I like about it: The approach function symbols are
handled, it is a pretty clear concept:
void f() {
}
f;
f is a function, you can take the address of it and call it and that's
it. So if you just write it down, it makes sense that it gets called.
Not so for delegates, function objects, ... Sounds sane to me, I like
it.
About properties:
In short, I died a little reading it.
I know we have UFCS, but @properties are meant to emulate a field, so
the semantics should be as close to a field as possible. Ideally,
identical.
Especially the part about module level properties made me crazy:
@property double fun(int x, double y) { assert(x == 42 && y == 43);
return y; }
42.fun = 43;
reads to me: The integer 42 has a property called fun, which gets
assigned 43???
If we special case properties, we might as well disallow UFCS for them,
which makes sense, because you can not define a field external to an
object either.
So the proposal for module level properties, would be right exactly the
other way round (emulating global variables):
private int myCoolSetting_;
@property int myCoolSetting() {
return myCoolSetting_;
}
@property void myCoolSetting(int setting) {
enforce(setting>0 && setting<10, "Invalid setting!");
myCoolSetting_=setting;
}
myCoolSetting=8; // Ok.
That is what properties are all about.
The part, about taking the address of a property, is fine as long as we
allow fields to be declared with @property as I already suggested, with
the following semantics:
@property int a;
would be lowered to:
private int __a;
@property void a(int a_) {
__a=a_;
}
@property int a() {
return __a;
}
in order to ensure that @property declared fields and properties
declared as functions do really have the same semantics.
If you don't think about properties as fields, than I understand Walters
suggestion about removing @property completely and we could as well do
it.
UFCS with properties, makes little to no sense. Because well the name
already suggests: "Uniform Function Calling Syntax", properties are not
about calling functions. Allowing UFCS would offer the possibility of
adding some kind of dynamic properties/fields to an object, but the code
samples with integers and especially the problem with module level
properties suggests that this causes more problems than it is worth.
properties -> no UFCS and we have a sane world!
Best regards,
Robert
P.S.: Things like
int a = 4.2.truncated;
do make sense, but UFCS and optional parentheses would do the trick too,
so no need to abuse properties there.
Re: Expanding Phobos from a flat hierachy
Ha! Great, I missed that. I thought it was vibe.d specific. Thanks! On Wed, 2013-02-06 at 22:15 +0100, Jakob Ovrum wrote: > There is a competing project doing just that: > > https://github.com/rejectedsoftware/dub
Re: DIP25 draft available for destruction
What happened to the scope storage class for parameters. Wouldn't this solve the problems, with the simple rule that you are not allowed to pass transient objects by reference if the parameter was not declared with scope? And if I understood correctly, the compiler is already capable of locally ensuring that the address does not escape (to ensure the scope requirement), so we are all set? Maybe even simpler, so that the approach also works with variadic template functions: All ref/pointer parameters of a trusted/safe method are automatically scope. For the addressOf method, I think it would be needed far too often. Think about std.stdio.readf() for example. It would really be annoying. Best regards, Robert On Wed, 2013-02-06 at 02:38 -0500, Andrei Alexandrescu wrote: > Probably it'll need a fair amount of tweaking. Anyhow it's in > destroyable form. > > http://wiki.dlang.org/DIP25 > > > Thanks, > > Andrei
Re: make @safe "non-escapable"?
> So this would be the behavior?
>
>@system {
> int test1() {} //@system
> int test1() @safe {}//of course!
> int test1() @trusted {} //of course!
> a = b;
>}
Yeah.
>
>@trusted { //disallowed for (bulk) function/type declarations
> //intended only for bits of code or for functions:
> //Otherwise an easy unchecked breeding ground for
> bugs!
> int test1() {} //error
> int test1() @safe {}//error
> int test1() @system {} //error
> int test1() @trusted {} //error, yes it is, even if explicit
> a = b;
>}
Why would the @safe definition be an error?
>
>@safe {
> int test1() {} //@safe
> int test1() @trusted {} //will happen from time to time.
> int test1() @system {} //error, cannot weaken code's
> restrictions
> a = b; //only if safe
>}
The @trusted definition must not be allowed either. @trusted good is as
good as @system code in this context, because the compiler guarantees
nothing.
Re: On DIP 23
Oops. I kinda missed the complete discussion about this. I am sure
someone else already wrote something similar, so just ignore the post.
Best regards,
Robert
On Wed, 2013-02-06 at 23:10 +0100, Robert wrote:
> Well first what I like about it: The approach function symbols are
> handled, it is a pretty clear concept:
>
> void f() {
> }
>
> f;
>
> f is a function, you can take the address of it and call it and that's
> it. So if you just write it down, it makes sense that it gets called.
> Not so for delegates, function objects, ... Sounds sane to me, I like
> it.
>
> About properties:
>
> In short, I died a little reading it.
>
> I know we have UFCS, but @properties are meant to emulate a field, so
> the semantics should be as close to a field as possible. Ideally,
> identical.
>
> Especially the part about module level properties made me crazy:
> @property double fun(int x, double y) { assert(x == 42 && y == 43);
> return y; }
> 42.fun = 43;
>
> reads to me: The integer 42 has a property called fun, which gets
> assigned 43???
>
> If we special case properties, we might as well disallow UFCS for them,
> which makes sense, because you can not define a field external to an
> object either.
>
> So the proposal for module level properties, would be right exactly the
> other way round (emulating global variables):
> private int myCoolSetting_;
> @property int myCoolSetting() {
> return myCoolSetting_;
> }
> @property void myCoolSetting(int setting) {
> enforce(setting>0 && setting<10, "Invalid setting!");
> myCoolSetting_=setting;
> }
>
> myCoolSetting=8; // Ok.
>
> That is what properties are all about.
>
> The part, about taking the address of a property, is fine as long as we
> allow fields to be declared with @property as I already suggested, with
> the following semantics:
>
> @property int a;
>
> would be lowered to:
>
> private int __a;
>
> @property void a(int a_) {
> __a=a_;
> }
>
> @property int a() {
> return __a;
> }
>
> in order to ensure that @property declared fields and properties
> declared as functions do really have the same semantics.
>
> If you don't think about properties as fields, than I understand Walters
> suggestion about removing @property completely and we could as well do
> it.
>
> UFCS with properties, makes little to no sense. Because well the name
> already suggests: "Uniform Function Calling Syntax", properties are not
> about calling functions. Allowing UFCS would offer the possibility of
> adding some kind of dynamic properties/fields to an object, but the code
> samples with integers and especially the problem with module level
> properties suggests that this causes more problems than it is worth.
>
> properties -> no UFCS and we have a sane world!
>
> Best regards,
>
> Robert
>
> P.S.: Things like
> int a = 4.2.truncated;
>
> do make sense, but UFCS and optional parentheses would do the trick too,
> so no need to abuse properties there.
>
>
>
Re: DIP23 draft: Fixing properties redux
It is not feature creep, it is properties done right. If not done this way, than honestly I don't know what properties are good for any way. We could use set/get methods just as well. If properties done right are feature creep, than properties per se are feature creep, which is debatable. But if we keep them, we should do them right. Maybe you can elaborate what properties are good for, if not for avoiding trivial set/get methods? -> Please really do that, because I am having a hard time understanding your reasoning. On Tue, 2013-02-05 at 08:31 -0500, Andrei Alexandrescu wrote: > The problem with this approach is feature creep - there will always > be > yet another possible case in which a feature helps some case. We need > to > put a halt on that.
Re: make @safe "non-escapable"?
The purpose of my proposal was to be able to sandbox code. It is quite different, whether you allow the sandboxed code calling a trusted function, you declared or allowing the sandboxed code to declare a trusted function, which would simply break the sandbox. On Thu, 2013-02-07 at 01:07 +0100, Era Scarecrow wrote: > True, but if you have one or two functions that break @safe but > you know are safe, then you need to override it. Otherwise you > have extra hoops to go through. If @safe code can't call @trusted > code, then this is a non-issue (as it's just another step/tier > towards safe).
Re: make @safe "non-escapable"?
Ok. Now I see what you mean. Good point, maybe it makes sense to extend
my proposal to simply state that @trusted, @system and @safe are simple
not overridable.
On Thu, 2013-02-07 at 01:07 +0100, Era Scarecrow wrote:
> >>@trusted { //disallowed for (bulk) function/type
> >> declarations
> >> //intended only for bits of code or for
> >> functions:
> >> //Otherwise an easy unchecked breeding ground
> >> for bugs!
> >> int test1() {} //error
> >> int test1() @safe {}//error
> >> int test1() @system {} //error
> >> int test1() @trusted {} //error, yes it is
> >> //even if explicit
> >> a = b;
> >>}
> >
> > Why would the @safe definition be an error?
>
> Because getting adding functions to a @trusted area would allow
> some lazy programmers to say 'it just works', it would be so easy
> to just remove @safe (and it would work). In general @trusted
> (code blocks) in my mind shouldn't allow function/structs/any
> type of extra declarations as it would be so easy to make it
> 'seem safe' while not properly checked, or adding a new function
> in while not wanting to move it back and forth between writing &
> testing.
>
> Sides allowing @safe in a @trusted zone while nothing else works
> doesn't make sense. It would be better to disallow period all
> rather than give an easy route for problems later. At least with
> @system and @safe code you know where you stand.
Re: Expanding Phobos from a flat hierachy
On Thu, 2013-02-07 at 09:45 +0100, Jacob Carlborg wrote: > Yes, I would be interested. I don't know what would be the best > communication channel. Great! :-) I think for now, maybe this mailing list is not the worst place. (At least I don't know a better one) Best regards, Robert
Re: Expanding Phobos from a flat hierachy
As Sönke Ludwig seems to work on something very similar, it might make sense to join forces with him too. I will look into both implementations next week, to see where we stand. > > As I said, I will replace Ruby with D, that includes the DSL. It's the > only place where Ruby is used. The rest is D. >
Re: Expanding Phobos from a flat hierachy
> I think the opposite. When we think about more concepts in > Phobos, like gui, serialization, cryptography and so on, we > will be able to create the right amount of hierarchy with > distinguishable names. I'm in favor of a big batteries > included library. Yeah, but I still think that breaking independent parts up in independent projects, will make the whole thing more manageable. If some of these projects happen to be within the std package and be installed by default, that is fine. Best regards, Robert
Re: DIP25 draft available for destruction
The solution to this problem has been posted already many times, simply
allow fields to be marked with @property too, having the compiler lower
it to a private field with trivial setter/getter method.
As I already mentioned, I don't really see the point of properties at
all, if they are not interchangeable with fields. We could as well use
setXXX/getXXX as in Java.
On Wed, 2013-02-06 at 22:06 -0800, Walter Bright wrote:
> Properties are always going to be subsets of fields. For example,
>
> @property int foo() { return 3; }
>
> is never going to work with trying to get the address of 3. Trying to
> make it
> work would be a quixotic quest of dubious utility. I.e. I disagree
> that it is a
> serious impairment.
Re: On DIP 23
> Heh, after that many topics and discussion I have started to > think it would have been better if initial proposal to remove > them altogether succeeded. Same feeling here. But I'll try to be constructive and I hope I find the time to write yet another DIP about properties next week. UFCS and properties just don't go together.
Taking address of properties
Properties provide a means of access control to fields. (Range checks, only readable, only writable, triggering a signal on change, ...) So as posted a few times, taking the address of the ref return value of a property is of no value at all. If you want someone to be able to take the address of a field, you should make it simply public (without @property), because the @property accessor methods won't gain you anything in this case. Having said this, I think the solution to the & operator is pretty straight forward, it takes the address of the accessor function, which in fact might me useful at times, but it never takes the address of the return value. (This only applies to properties, for functions simply do something like &(func()) to get the address of the return value.) Tada. Problem solved :-) I can remember Adam D. Ruppe saying that he would rather have it hidden completely that the property is accessed by methods, so that taking the address of the function would not be possible. I have to say, that this does not feel right for a system programming language and it does not really improve things, especially with @property fields. Instead of hiding that properties are functions, we hide that there might be a real field behind those properties. Best regards, Robert
Re: Taking address of properties
Good point, but I think that this is pretty much a corner case where it occasionally might be useful, but it does not rectify the consequences: The moment you are allowed to take the address, you are stuck with the ref returning accessor and can not change it later to a get/set pair. An easy solution: auto a=myrange.front; someCFunc(&a); myrange.front=a; It is a little more to write, and maybe a tad slower (depending on the smartness of the compiler), but we maintain the property guarantees, which seems to me to be a very valuable goal. Best regards, Robert On Thu, 2013-02-07 at 19:43 +0100, FG wrote: > Once again. Ref returns are commonly used in ranges. > I'd say that being able to take address of someRange.front is good for > example for interoperability with external C libraries. > Temporarily using a pointer here should be fine. >
Re: Taking address of properties
It depends on how we are going to define properties and with all the
arguments in the discussions it seems to me that the only sane way to
design properties is as simple front ends for private fields (which is
my understanding of properties anyway).
But with optional parantheses the @property would also not be necessary
for this case. So such use cases would need to be handled by normal
functions. It would simply not be a property by definition.
Redirecting access would not be the purpose of properties but for
functions returning refs. And you are free to take the address then with
&arr.front().
> @property ref T front(T[] arr) { return arr[0];}
Do you have any other UFCS examples, where @property would seem to be
appropriate?
>
> This all comes down to an incorrect belief that properties are simply
> front ends for private variables. They are not, even when many languages
> make such things necessary or easy to implement (objective C comes to
> mind).
>
> There are plenty of different uses of properties, and redirecting access
> to another variable (as does the above function) is certainly a valid
> use. I don't think we should make rules that are focused on specific use
> cases while discarding or diminishing others.
It all depends on definitions. If you define an integer as an integral
type, you would not expect it to do floating point arithmetic. Although
there are use cases for floating point operations, but an integer is
just the wrong tool for it.
Re: Taking address of properties
Just to be clear here, with DIP23 in place, the syntax at the caller
side for:
@property ref T front(T[] arr) { return arr[0];}
would not change if you remove the @property. So little code breakage
here and the code that breaks is easily fixed by removing @property.
Re: DIP23 Counter Proposal
> > struct S
> > {
> > @property int i;
> > }
> >
You missed the point. When this gets lowered to accessor functions and a
private variable, you ensure that you can later on add your magic soup,
without breaking code that relied on i being a real field. (E.g. taking
the address, using +=, -=, ...)
Although += or -= can still be added for properties, but the important
thing is, that for an @property declared field nothing is possible, that
is not also possible with a property created by manually writing set/get
methods.
Re: Taking address of properties
On Thu, 2013-02-07 at 16:08 -0500, Steven Schveighoffer wrote: > int delegate()[] arr; > > arr.front(); That's part of the mess we are trying to clean up here? As of DIP 23, you would have to do arr.front()() in order to actually call the delegate. The current behaviour is also that you have to do arr.front()() in order to actually call the function. So with DIP23 in effect you would actually have to remove @property in order to be backwards compatible.
Re: DIP23 Counter Proposal
I am not completely against this, but it feels quite artificial to make
a builtin feature complete this way. If we implement the property stuff
completely via library methods, I would like it more, but if it is
documented properly, might not be too bad:
struct S {
mixin(property(int, "i"));
}
On Thu, 2013-02-07 at 16:12 -0500, Steven Schveighoffer wrote:
> struct S
> {
> mixin(boilerplateProperty("i"));
> }
Re: DIP23 Counter Proposal
That is actually a good point. On Thu, 2013-02-07 at 22:55 +0100, Jonathan M Davis wrote: > Except that mixins are generally unacceptable in APIs, because they > don't end > up in the documentation. That means that this works only if you don't > care > about documentation. So, it's almost useless. Putting @property on > there also > looks better but isn't that big a deal. However, the lack of > documentation > _is_ a big deal.
Re: Taking address of properties
On Fri, 2013-02-08 at 12:52 -0500, Steven Schveighoffer wrote: > > Then it doesn't conform to the range API, where front is a property. I can't find anything about that front has to be a property here: http://dlang.org/phobos/std_range.html#isInputRange all it states that you can get the current element by issuing: r.front which would still be possible with the optional parentheses of DIP23. > > > front for arrays would not be a property for two reasons: > > 1. front is a UFCS function, I think supporting UFCS with properties > is > > just getting it wrong, have a look at DIP 23 if you don't believe > me. > > I don't believe you. DIP23 has flaws. Care to explain? "just > wrong" > isn't an explanation. Look at the section "No module-level properties". Why not?! That's a perfectly valid use of properties. The proposal disallows module-level properties, but instead allows: 42.fun = 43; which reads like: assign 43 to the fun property of 42. We get this really obscure feature but disallowing module-level properties? If that is not wrong, than I don't know what is. > > > 2. My current version, would not allow properties to return ref, but > > instead a property is a property if it defines a getter or a setter > or > > both with the following exact definition: > > > > @property void a(T val); > > @property T a(); > > This is a severe reduction in expression, we should not be looking > for > extra ways to invalidate existing code unless there is an extremely > good > reason. "Just wrong" is not it. I have really good reasons and I hope I'll explain them well enough in the DIP I am currently writing. You already suggested that keeping compatibility to a broken implementation is not worth it, simply removing the @property in cases where there are no longer allowed, seems not too hard a change to me, especially if we agree that we have to break compatibility in one way or the other.
Re: Taking address of properties
First of all, thanks for this very insight full discussion. I start to understand the other side. :-) On Fri, 2013-02-08 at 15:13 -0500, Steven Schveighoffer wrote: > On Fri, 08 Feb 2013 14:05:40 -0500, Robert wrote: > > > On Fri, 2013-02-08 at 12:52 -0500, Steven Schveighoffer wrote: > >> > >> Then it doesn't conform to the range API, where front is a property. > > I can't find anything about that front has to be a property here: > > http://dlang.org/phobos/std_range.html#isInputRange > > > > all it states that you can get the current element by issuing: > > r.front > > which would still be possible with the optional parentheses of DIP23. > > Technically this is true. But the expectation is that r.front is a > property/field, not a function. That aspect is difficult to capture in a > template, especially in the current implementation where @property on a > getter is essentially redundant info. In a template you should not care what it actually is, as long as this works: auto h=r.front; (stolen from the implementation of isForwardRange), if I understood your argument correctly. > > In fact, the only case where a properly-implemented @property would be > required on a getter is for delegate properties. I would argue that if > @property worked correctly, it would be possible and correct to require > r.front to be a property in that template. I don't understand, what is the exact problem with: r.front()()? Despite not matching the specification regarding no parentheses for properties? > > Module level properties pose an issue, because @property does not > designate whether a property is a getter or a setter. In particular, a > single-arg property function could be considered both a module property > setter, or a UFCS property getter. > > So your issue is not really that UFCS properties are wrong, it's that > disabling module-level properties is wrong. I agree with you, but at the > same time, module level properties are not as common or useful as UFCS. Sure UFCS for functions, I suggest that UFCS for properties does not make a lot of sense. (If you apply my definition of a property and accept simple functions with optional parentheses as better way.) I am sorry, I don't understand what you mean here with: > In fact, one could argue they are more confusing since module scope is one > of the only scopes that can be obscured. > > There are other possible solutions, such as designating something as a > getter specifically, or adding more syntax (i.e. decorating the first > parameter as 'this' for a module-level UFCS getter). But for now, the > easiest thing is to disallow one or the other, and since UFCS properties > are pretty much essential in Phobos, he's disabling the module level > properties. > > The 42.fun = 43 example, just about everything is wrong with that. > > Look here is another function that D "allows": > > void increment(int x); > > What is that exactly supposed to do? > > 42.increment(); // what? > increment(42); // what? > > Design and naming of functions is never going to be a problem that the > compiler can solve. Point taken. But my point is, that with optional parentheses UFCS properties are not needed, so the cleaner solution is to forbid UFCS properties. (See my DIP for further reasoning when it is ready) > > My point on that was, if something works but is not supposed to, we > shouldn't have to worry about keeping that code working. @property in its > current form is NOT implemented as it was designed. There is no > requirement to keep existing behavior that doesn't correctly work. > > In the example given, @property is supposed to ban the use of parentheses > according to the spec, but it doesn't. In fact, in the case of a > @property that returns a delegate, it REQUIRES the extra parentheses. > This is a bug, and not something to try and keep working. Despite being inconsistent with the specification, what are the problems with that? > > On the other hand, ref @properties is NOT a bug, it functions as > designed. Whether to remove it or not is certainly a discussion we can > have, but it's not buggy behavior. See the difference? But the documentation of properties: http://dlang.org/property.html in the section about user defined properties also states in the very first sentence: Properties are functions that can be syntactically treated as if they were fields or variables. which is clearly not true at the moment. If this sentence got removed and replaced with a big fat warning that properties are not exchangeable with fields, this would be the least that should be d
Re: Taking address of properties
On Fri, 2013-02-08 at 22:15 +0100, FG wrote: > Or should void front(T val) remain a > @property, while ref T front() becomes a plain function? Exactly.
DIP26: properties defined
Ok. Here finally it is: http://wiki.dlang.org/DIP26 Best regards, Robert
Re: DIP26: properties defined
I am claiming that if we restrict ourselves to the property concept explained in the DIP, then the range API would no longer depend on front being a property, it can also be a function returning ref, which is perfectly legal for UFCS. I am further claiming that properties via get/set methods don't actually make sense outside of the entity that define them, I am glad if you could give an actual example that would prove me wrong. And because properties are treated (apart from allowing = to call the set method) exactly like normal functions, you should note no difference. It feels to me, that most problems arise due to the fact that we try to make properties like fields (forbidding parentheses), which make them essentially incompatible to functions, resulting in making all sorts of things properties, which actually aren't, just so that no template breaks. Maybe I should make this more clear in the DIP. On Fri, 2013-02-08 at 22:04 -0800, Jonathan M Davis wrote: > I completely disagree with disallowing UFCS properties. Not only is > it > outright required for arrays, but it's currently possible to turn > anything > into a range (even types over which you have no control) simply by > defining the > functions (including property functions) for it externally. And you > could do > the same with most any API required by a template. If UFCS properties > were > disallowed, then that would become impossible for any API which > included > properties. That's unnecessarily restrictive.
Re: DIP26: properties defined
Has anyone actually read the DIP?
Simply don't call it property.
On Sat, 2013-02-09 at 08:45 +0100, FG wrote:
> On 2013-02-09 08:19, Dmitry Olshansky wrote:
> >> NoUFCS for properties
> >
> >> Properties protect the access to a field of an entity
> >> (class/struct/module),
> >> so they actually have to be defined within the entity they belong to, just
> >> as
> >> a field would.
> >
> > Rubbish.
> >
> > std.array:
> >
> > @property auto front(T)(T[] arr)
> > {
> > return arr[0];
> > }
> >
>
> Yeah, banning UFCS for properties is too farfetched.
Re: DIP26: properties defined
As you can't actually encapsulate the array with free functions just do:
ref T front(T)(T[] arr);
There is no value in using an actual setter.
If you really want encapsulation, just do:
struct EncapsulatedArray(T) {
T front() @property;
void front(T value) @property;
private T[] arr_;
}
On Sat, 2013-02-09 at 12:43 +0100, FG wrote:
> On 2013-02-09 12:32, Robert wrote:
> > Has anyone actually read the DIP?
> >
> > Simply don't call it property.
>
> Fine for getters but this time it will break things for setters:
>
> @property void front(T)(T[] arr, T elem) {...}
>
> and either all code with assignments would have to be changed
> or assignments remain allowed for functions -- neither is good.
>
Re: Partial modification of DIP23 to allow module level property
> arrays are by far the most common type of range, I think that it's > just asking > for trouble to allow their front or back to be used with parens. Except you ebrace the idea that front is a function (property or not) and make parens work in all cases. Why not do it the other way round, front has to be a function property or not. Seems to work far better, it is a simple rule. No performance penalty as trivial set/get can easily be lined in, ...
Re: Partial modification of DIP23 to allow module level property
On Sat, 2013-02-09 at 04:12 -0800, Jonathan M Davis wrote: > It fails miserably when the element type of a range is callable. > That's the > main reason that @property was introduced in the first place. It does not, you would have to do: front()(); Always! front is guaranteed to be a function, (I tried to explain why in the DIP), so this is consistent behaviour, meaning it will work with templates.
DIP26 updated
I added sections - Upgrade path - Conclusion to better prove my point and the concept as such.
Re: DIP26: properties defined
The DIP actually solves this. On Sat, 2013-02-09 at 02:31 -0800, Jonathan M Davis wrote: > I just went over this with Kenji in his thread "Partial modification > of DIP23 > to allow module level property." You _must_ be able to rely on front > being a > property. > > With any API that templates use, the exact syntax of the functions or > properties used must be defined. Otherwise, you're going to be screwed > by > things like a templated function using parens to access a property > working in > some cases and not in others (because some types defined it as a > function > whereas others defined it as a property). Even worse, it _completely_ > breaks > properties which return delegates. front() _must_ make the call on the > return > value of front and not just call front. If front can sometimes be a > function > or sometimes be a property, then the code will function drastically > differently > depending on whether one or two sets of parens were used. > > It's bad enough that parenless function calls are legal, but if you > let a part > of your API be either a property or a function, you're asking for it. > Code > _will_ break at some point because of that inconsistency. Generic just > code > can't afford it. And when we're talking about something in the > standard > library, it's that much more critical. > > - Jonathan M Davis
Re: DIP26: properties defined
I am going to consider these. Thanks!
On Fri, 2013-02-08 at 22:13 -0500, Michel Fortin wrote:
> On 2013-02-08 23:53:30 +0000, Robert said:
>
> > Ok. Here finally it is:
> >
> > http://wiki.dlang.org/DIP26
>
> This is pretty much exactly how I think properties should work. There's
> two possible benefits you may to have overlooked…
>
> One benefit of the "@property T foo;" syntax that does the boilerplate
> code for you over using a plain variable: the getter and setter
> generated are virtual in a class, so a derived class can override them.
> Doesn't work with a plain variable.
>
> Another possible benefit that we could have is the ability to use the
> default getter but to provide your own setter implementation by just
> declaring it:
>
> @property int a;
> @property void a(int value) { __a = value; refresh(); }
>
> Much cleaner than this:
>
> private int _a;
> @property int a() { return _a; }
> @property void a(int value) { _a = value; refresh(); }
>
> It's really great to not have to write boilerplate functions when
> default behaviour is perfectly fine. I've been using Objective-C for a
> while now and the recent changes where it automatically synthesize a
> variable, a getter, and a setter when declaring a property (unless you
> provide your own) are truly delightful.
>
Re: DIP26: properties defined
On Sat, 2013-02-09 at 08:28 +0100, deadalnix wrote: > Taking the address of a property <= no. It I take the address of > an int, I get an int* or an error because it is invalid. Not a > delegate ! > No UFCS for properties <= no. > Behaviour like functions <= WTF should properties behave > differently if the return a function ? You are still thinking of properties as fields. Which does not work reliable in any proposal and actually can not, that is the reason for encapsulation in the first place. My arguments against UFCS for properties make a lot of sense if you think about it and result in a very clean implementation, with little breakage and the added benefit of actually having something that deserves to be called property. The other proposals try to solve the issue of functions returning functions being inconsistent across real functions and some property like thing that tries (badly) to mimic a field, by making property just more non sensical, instead of tackling the root cause of the problem: We can not mimic fields and in fact there is absolutely no reason to do so, if you think about it, you don't really want that, otherwise all books about OOP would be wrong.
Re: documentable unittest
On Thu, 2013-02-07 at 17:20 -0800, H. S. Teoh wrote: > How cool would that be?? Awesome!
Re: DIP26: properties defined
On Sat, 2013-02-09 at 16:17 +0100, deadalnix wrote: > Also, you don't address most of the point Jonathan > raises, and that should probably be a sign that you are not > mastering the topic enough. Funny enough, when I read your posts I get the feeling you did not even read the DIP. Enough insulting for now?
Re: DIP26: properties defined
I already thought about this too, good enough that D choose not to use final for const variables like Java does. On Sat, 2013-02-09 at 12:54 -0500, Michel Fortin wrote: > On 2013-02-09 15:22:28 +, Jacob Carlborg said: > > > I completely agree, I really like it. Do we want to be able to use > > attributes like "final", and perhaps others, when declaring a property > > field: > > > > @property final int a; > > > > The lowered functions would have the "final" attribute attached to them > > self. > > That'd make a lot of sense. >
Re: DIP26: properties defined
> // this is a property
> int foo() {...}
It is, if you consider properties to be functions that can be called
without parentheses. Which is quite a lame definition of property if you
ask me.
But yeah my proposal makes properties to be considered functions, just
with some guarantees regarding encapsulation and the special syntax that
prop=a;
means: prop(a);
Actually Michel Fortin summarizes the DIP quite to the point:
> So in short, this proposal is that @property does only two things
when
> applied to a function: it enables the setter syntax and it changes
the
> overload rules.
>
In addition it restricts the setter syntax (prop=a) to be interpreted in
a non UFCS way, meaning there will be no setter methods with two
parameters. (Not accounting for the implicit this parameter)
Re: DIP26: properties defined
> You must be able to rely on front always being used without parens, > and you > must be able to rely on front() doing a call on the return value > rather than > simply calling front. Why? Think about it, this thinking comes from the fact that it was considered to be a good idea that front could be anything including a field or even an enum. The question is why would we want to allow this in the first place. It is never used in the standard library, it breaks encapsulation and every field or enum can easily be turned into a trivial function. Maybe you are still referring to an early version of the DIP where I put there a sentence, (with a bad feeling already) that properties must not be called with (). I fixed this very bad mistake very soon afterwards, maybe you want to have another look?
Re: DIP26: properties defined
On Fri, 2013-02-08 at 22:00 -0800, Jonathan M Davis wrote: > It would be simple enough to make it so that the compiler used auto > ref in the > lowered version and just make the variable itself int, though the DIP > obviously doesn't say that. That would be impossible for virtual functions in a class. What the compiler could do, is simply provide both. This has to be thought through, what is important is that it is very clear what the compiler produces. As properties are meant to be assigned (which implies a copy at some point), you usually try to keep them small anyway or making them a class so that you only have to assign a reference. So I think it is not a bad choice to have the compiler simply generate the most simple trivial form, taking the argument by value. If you really want something different in some special application, you may still provide the functions on your own. Having said that, I really don't mind having the compiler produce both, if people think this is a good idea.
Re: Taking address of properties
Ok, at the very first I have to make clear that my DIP is about changing
the actual specification, not trying to make the implementation to match
the specification, because in my view of things, the specification is
the problem.
Properties in my proposal are no longer about optional parentheses ore
forbidden parentheses. Properties are a concept hat benefits from the
fact, that parentheses are optional, but would work either way.
Reducing properties to functions with no parentheses is just not getting
it right as we can see with the problems we have.
>
> In the grand scheme of things, the fact that a range's front accessor is a
> property or a function is not technically important. But front being a
> property IS important for specific uses. You can't have it so that front
> is a function only when using it as a range, and a property when using it
> as a delegate getter.
In my DIP a property is a function and they behave the same, except that
prop=5; calls prop(5); if prop is a property.
>
> >> In fact, the only case where a properly-implemented @property would be
> >> required on a getter is for delegate properties. I would argue that if
> >> @property worked correctly, it would be possible and correct to require
> >> r.front to be a property in that template.
> > I don't understand, what is the exact problem with: r.front()()? Despite
> > not matching the specification regarding no parentheses for properties?
>
> The problem is, isInputRange does not require that it is a function, but
> you ARE requiring that by specifying arbitrary rules.
I think this has to be fixed, because it solves all ambiguities and
encourages good design.
>
> Imagine an infinite range (one which never ends), that returns exactly a
> specific delegate. Such a range could be implemented:
>
> struct infiniteDelegate
> {
> int delegate() front;
> enum empty = false;
> void popFront() {};
> }
It would, based on the current definition, yes. But what is it good for?
Why not simply write:
struct infiniteDelegate
{
int delegate() front();
bool empty() @property { return false; }
void popFront() {};
}
Where the body of front for example can ensure that the delegate is
actually set and not null or can change it if necessary, ...
I haven't applied @property to front in this example, because it would
not change anything, it would be required though if you provided a
setter and wanted to have front=something; work. Whether or not you
apply @property to read-only functions, depends on your use case, if you
want proper encapsulation, you would add @property and in case you want
a writable front at some time, you would add a setter. If you don't
consider encapsulation necessary, you would probably do not add
@property and return a ref if it has to be writable sometime.
> Actually, that is not true. Check out the definition of
> hasAssignableElements:
>
> http://dlang.org/phobos/std_range.html#.hasAssignableElements
>
> By your requirements, hasAssignableElements!(T[]) would necessarily always
> be false, since UFCS properties are banned, so array.front is not a
> property. You are saying, I can't assign to the front element of an
> array. That doesn't sit well with the rest of array's API.
Not true, the current definition of front for arrays is:
@property ref T front(T)(T[] a);
which would still work just the same, if you removed @property.
Strings are interesting as front returns a non ref dchar (obviously),
but they have no writable front anyway. If you would really have a use
case where you need an actual setter/getter for an array for example,
just do proper encapsulation in a struct/class. If you don't do that,
your setter could be bypassed anyway so the design is questionable at
best. (Which you could still achieve via alias this, if you really
wanted that.)
> void foo()
> {
>
> int x; // allowed
>
> x = 5; // applies to local scope, not module
> {
>int x; // error! shadows outer scope x.
> }
> }
>
> So the point is, a global property could possibly be obscured if you
> declared a local variable with the same name.
Same for instance variables and member functions.
>
> Note also that you can have struct-qualified properties (at least you
> should be able to, it seems Andrei's DIP does not allow it, but it's not
> at odds with UFCS). Those are just about equivalent to module-level
> properties, they just require specifying the struct name (and people have
> used this in clever ways to achieve good readable results).
Hmm, no real difference to struct/class properties:
import std.stdio;
int i;
void main() {
int i;
i=8;
writeln(".i: ", .i);
writeln(".i: ", testglobal.i);
}
Prints 0 both times. (The file was named testglobal.d)
> It certainly is true. They can be treated like fields for getting and
> setting, and I think "syntactically" means you access them like you would
> access a field.
>
> You mi
Re: DIP26 updated
> I can unequivocally say that I think that this DIP is a horrible idea. While > it may need some work, DIP 23 is worlds better. I definitely think that > @property should be implemented as originally intended save for the > unfortunate fact that we have to keep parenless function calls around. And > this DIP definitely isn't going in that direction at all. I'm completely > against anything which would involve not having @property on front, and I > think that it's a complete disaster to try and disallow UFCS properties. > > - Jonathan M Davis If you really think this way, then I really don't understand why you embraced my idea of: @property int a; so much. It does not make any sense at all, if property has not the meaning you seem to think it should have, when embracing this idea. If you allow @property qualified functions returning ref, then you basically consider public int a; a valid property and what should this @property int a; be good for? In fact, for the people who don't consider properties a means of encapsulation, but just about convenience syntax and forbidden parentheses, I completely understand why they think that @property int a; would be bullshit. If property does not mean encapsulation, then why should an @property qualified field mean encapsulation?!
Re: Taking address of properties
On Sun, 2013-02-10 at 13:40 +0100, Timon Gehr wrote: > Why does this justify a keyword? I think Walter's initial proposal of > getting rid of @property has more merit than this. Read the DIP? It is about encapsulation and making set functions callable with = in order to be compatible with ref returning functions: (Compatible from set function to ref returning function, not the other way round) and for the more expressive syntax: a=something; instead of a(something); and so that tools can easily extract what's a property. (For enabling access from scripting languages for example, like Qt does.) The one reason why we can not drop it, is that = calls the set function on properties. The reason why we should not, is that having such a cool straight forward feature for providing proper no-boilerplate encapsulation seems valuable in an OOP enabled language.
Re: Taking address of properties
> The reason why we should not, is that having such a cool > straight forward feature for providing proper no-boilerplate > encapsulation seems valuable in an OOP enabled language. > Provided we actually give properties this meaning in D, which is currently not the case.
Re: Taking address of properties
> > > > Read the DIP? > > Stop trolling. Agreed, sorry. But by reading some arguments that are posted over and over again, I just get the feeling that people don't even read it, which is kinda frustrating, as it was a lot of work. > > > It is about encapsulation > > Perfectly possible without DIP26 and encapsulation can be violated using > @property as given in DIP26 just as easily as without it. How?! I mean yeah, you can return a pointer to a field, that is correct. But apart from that, which might get forbidden too for properties (I have to think about it first), what do you mean? > > > and making set functions > > callable with = in order to be compatible with ref returning functions: > > (Compatible from set function to ref returning function, not the other > > way round) > > setter(2); Fine with me. What is the problem? > > > and for the more expressive syntax: > > a=something; > > That's not more expressive. If you want to state that the property should assume the given value, it is. Arguably not more than setA(something), but well it is a nice syntax and we stay compatible with ref returning functions and with the current implementation. > Use UDAs. True if this was the only reason. > > > The one reason why we can not drop it, is that = calls the set function > > on properties. > > So does ( ). And both are the case already. Yeah, which actually is a good thing, because we won't break much code. People have their code written according to the implementation not some specification, so if we keep most currently existing code running and get sane behaviour, I think this is a good thing, but ok there are people who seem to disagree. > > > The reason why we should not, is that having such a cool > > straight forward feature for providing proper no-boilerplate > > Boilerplate can be trivially automated. Also true, but integrating it into the language makes the property feature complete and well integrated.
Re: Taking address of properties
> How?! I mean yeah, you can return a pointer to a field, that is correct. > But apart from that, which might get forbidden too for properties (I > have to think about it first), what do you mean? > > I mean of course you can. Always. There are many ways: - alias this - some other function which returns the variable by ref/pointer - make the field public But the @property marked functions won't break it.
Re: Taking address of properties
On Sun, 2013-02-10 at 10:43 -0500, Steven Schveighoffer wrote:
> On Sun, 10 Feb 2013 07:09:52 -0500, Robert wrote:
>
> > Ok, at the very first I have to make clear that my DIP is about changing
> > the actual specification, not trying to make the implementation to match
> > the specification, because in my view of things, the specification is
> > the problem.
> >
> > Properties in my proposal are no longer about optional parentheses ore
> > forbidden parentheses. Properties are a concept hat benefits from the
> > fact, that parentheses are optional, but would work either way.
>
> We don't need a feature to implement encapsulation, it's quite possible
> without property specification. And your proposal does not guarantee
> encapsulation anyway.
We don't need it. -> Yes.
Would it be nice to have. -> Discuss-able.
Does it solve the issues we have. -> Yes.
Properties as such do guarantee encapsulation, if you access the fields
through the property methods. There is no way to forbid the programmer
to break it by other members, alias this, or what ever. But as you said
D is a systems programming language.
>
> Then why do we need special syntax? I don't see the point. This is just
> back to D1 properties.
Actually only two hard requirements:
1. Downwards-Compatibility with functions returning ref. (Downwards
means that you can replace a property with a function returning ref, but
not the other way round)
2. Backwards compatibility.
Not mandatory:
3. Nice syntax
Why do we need properties to be radically different than functions? This
breaks templates, except we try to make almost everything a property,
what DIP23 seems to do. All I do is strive for a clean concept what a
property actually is, instead of making everything a property just so
that templates work, but by giving up any meaning property could have.
>
> And who says what good design is? What if good design means low
> performance? What if performance is more important? How can you say you
> know the goals of every possible implementable object and whether
> encapsulation is entirely necessary for it? You are holding hostage a
> syntax feature on the concession that it play nice with your "requiring
> function call" rules.
I believe the principles of OOP are very well established and accepted.
And once again, you don't have to use properties if they don't match
your requirements. Also performance does not suffer from a trivial
get/set functions. (For classes make them final if needed)
>
> I don't think D should be dictating everything about how you write your
> properties and methods. This is a systems language, not a nanny language.
It does not dictate anything. You do accept that you can not do floating
point arithmetic with an integer? What's the difference with properties?
If the tool does not fit your need, don't use it.
> Because then I have to do:
>
> id.front()();
>
> To call the delegate. Not what I wanted to design. You are calling into
> question my design because it doesn't suit your DIP. Why is your DIP more
> important than my design?
You are questioning my DIP, because it does not match your design. How
is that better? Seriously this is just my point of view, you can agree
or not, all I am trying is to make sure that you understand why I think
it is good and to find possible flaws in it, by discussing it.
It establishes some semantics for properties, instead of simply making
basically everything a property, just so that templates work somehow.
The DIP increases uniformity among language features, instead of
decreasing it. Also I am obviously convinced that my DIP is a good
solution, otherwise I would not have proposed it.
> > which would still work just the same, if you removed @property.
>
> Right, the setter is not the reason we need @property on this, it's the
> getter. And only for delegate arrays. I should not have brought this
> example as a reason for UFCS setter properties.
Not if we simply accept: front()(); as the syntax to go. It might not
look as beautiful as front(), so if you think the syntax for this corner
case is just so utterly ugly that it has to be fixed, well then my
proposal is rubbish.
> import std.stdio;
> > int i;
> >
> > void main() {
> > int i;
> > i=8;
> > writeln(".i: ", .i);
> > writeln(".i: ", testglobal.i);
> > }
> >
> > Prints 0 both times. (The file was named testglobal.d)
>
> I don't know what this example is trying to prove. I don't see any
> properties here.
Hmm, maybe I misunderstood your argument against module level
properties. (The example works the same if i was a property)
So what did you mean by:
DIP26 reworked
Hi guys! Based on the feedback I got in discussions on this newsgroup I reworked DIP26. The new version - emphasizes less on encapsulation as people seem to have a problem with phrases I used. (And I really got carried away a bit on this one) - Clarified the section about UFCS as people seem to think that I am crazy and trying to destroy the range interface for arrays. - In general I tried to make things a bit more clear, especially what it is all about. Thanks for the feedback! Best regards, Robert
Re: DIP26 reworked
On Sun, 2013-02-17 at 04:18 +0100, deadalnix wrote: > It still introduce limitation for very poor reasons. You assumed > people didn't understood you DIP but in fact, people did. Could you please explain what about the DIP is a limitation and how it affects you in practice? Maybe people understood it correctly, but I still don't understand what people don't like. So if you could explain how the DIP affects your code and why you don't like that, this would really help me to understand what the problem is. Thanks!
Re: DIP26 reworked
> I'm sorry this is reversed logic. You introduce limitation (IE no > UFCS setter for instance) it is up to you to justify the tradeoff. I thought I did, if you disagree I think it is not too much to ask why? I surely might have missed really good use cases, that is why I want to discuss it, so if you have one, please tell me. > For instance > typeof(a) == int and typeof(&a) == function is really bad. Plus > it cascade into all kind of possible weird cases. What about > ternary operator ? Coma expressions ? I in fact forgot about those issues, I will check them out. Thanks! Although this critique does not really apply to DIP26, but rather DIP23 (they still need to be resolved as DIP26 builds on the concept of optional parentheses of DIP23) but I would like to know what is bad about the things DIP26 introduces and most importantly why. Thanks again for constructive feedback.
Re: The DUB package manager
> There are no package managers out of the box for Mac OS X or Windows. > That's right, so we have to provide a custom way. Which also is necessary for non root installs and for experimentation and trying out (your own) packages. Nevertheless I think in the long run it should not be a problem to integrate with: http://openbuildservice.org/ in order to also provide packages for distributions? Ideally the build systems configuration contains everything needed to automatically create a spec file for Fedora, for example.
Re: Update vibe.d Phobos documentation?
On Wed, 2013-02-20 at 23:13 +0100, Sönke Ludwig wrote: > Am 20.02.2013 18:45, schrieb Rob T: > > I use this experimental sample website regularly for Phobos > > documentation because it's organized much better than what is on the > > official website. > > > > Example: > > http://vibed.org/temp/d-programming-language.org/phobos/std/array.html Hmm. While I really like the layout, because it is so much more readable then the dlang.org version, I wonder how I get information about members of a class, e.g. for RedBlackTree: http://vibed.org/temp/d-programming-language.org/phobos/std/container/RedBlackTree.html I only get the creator functions. Funnily the link in functions to redBlackTree leads to a 'page not found'. It also seems that DList has no members? Best regards, Robert
Re: Update vibe.d Phobos documentation?
On Sat, 2013-02-23 at 11:55 +0100, Sönke Ludwig wrote: > Fixed. http://vibed.org/temp/d-programming-language.org/phobos/std/container/RedBlackTree.html I love it! :-) It is just so much more readable! Thanks a lot for your efforts!
Re: DIP27 available for destruction
On Tue, 2013-02-26 at 22:03 +0400, Dmitry Olshansky wrote: > The fact that empty can't be "enum empty = false;" is a problem since > that's how infinite ranges are statically distinguished. Thanks for the feedback on DIP26 :-) The isInfinite template is also satisfied if empty is a static function because of CTFE) Best regards, Robert
building phobos fails because of oom
Hi guys! I just tried to build the current phobos (master branch) in order to try out a pull request: https://github.com/D-Programming-Language/dmd/pull/1660 -> Thanks a lot Kenji! but the build fails, because it is killed by my dear friend, the oom-killer. (I have 4 GB of RAM) Is there any quick and dirty workaround available? Maybe I can tweak some kernel setting for the oom-killer? How much available memory would I need for successfully building phobos? Thanks! Best regards, Robert
Re: Slower than Python
Hm, just recently a friend of mine and I hacked together at the FB hacking cup, he in python and I in D. My solutions always were at least faster by a factor of 80. For your example, I could not get a factor of 80, but with -inline it is at least faster than the python version (about 30% faster on my machine) Best regards, Robert
having a folder containing dots in the import path
Hi guys! I just made the discovery that putting a D source file named "d" in a directory named "a.b.c" with a module declaration like: module a.b.c.d; works as expected (can be imported via import a.b.c.d;). This is actually pretty cool and useful (and I hope nobody removes this feature now, that I mentioned it!). I was just wondering if it is ok to rely on this or if it is unintended/unspecified behaviour that might change? Thanks! Best regards, Robert
Re: having a folder containing dots in the import path
> This only works if you explicitly provide the module to DMD. If you > only pass the -I import switch to find the module it will not compile. > > I wouldn't call this a feature, but rather a bug. It's probably a case > of a string compare returning true instead of actually verifying where > the module is. At best this could be a feature enhancement, but I > don't think it will fly. > > There is also an opposite bug: > http://d.puremagic.com/issues/show_bug.cgi?id=9194 You are right, this is sad :-( Thanks. I think it would actually be pretty neat to support this properly, because there are times where you end up having a directory containing a single directory containing a single directory, ... just because of the module path. Having to traverse three folders just to get to the source code could easily be avoided if this was actually an official feature. I filed a bug report: http://d.puremagic.com/issues/show_bug.cgi?id=9664 If you have some argument why this would be a bad idea, feel free to add a comment. Best regards, Robert
Re: std.asio?
On Mon, 2013-03-11 at 17:06 +0100, Martin Drasar wrote: > Hi, > > I started to work on a networking heavy project and I found out that > there is nothing like boost.asio in D's standard library. So I looked > around and discovered that vibe.d has nice fiber-based asynchronous > library, but sadly it does not play along well with threads. Then I > looked some more and found nothing else... (this can of course mean that > I can't search) > > I have hacked a solution that implements more or less what I need, but > it got me thinking that such thing would be very useful in standard > library. So I have some questions (in descending order of importance): > > - Is there some asynchronous networking library for D out there? > - Is somebody working on such library? > - Is there a plan to work on such library that may be held back by > insufficient manpower or by yet-to-be-added libraries like the new I/O? > - If there is nothing and nobody is working on it, what would be the > best course of action if I wanted to do it? > DIP -> implementation -> experimetnal -> std? > list discussion -> implementation -> experimental -> std? > implementation <-> discussion -> experimental -> std? > some other permutation? > > Any other thoughts? > > Cheers, > Martin I had plans to implement something like this, but at the moment I am stuck with other important things. I absolutely agree that something like boost::asio::io_service should be part of the standard library, so the situation we have in C++ where every library implements its own event queue could be avoided. (E.g. the only really working way to use Qt and boost::asio together is by using multiple threads) I would love to avoid this in D. Ideally we would have asynchronous primitives and a synchronous interface compatible to regular streams like the upcoming std.stream based on fibers and an event queue. This way also higher level libraries building on std.stream like a db abstraction library would automatically offer asynchronous operation by simply replacing the used stream with an asynchronous fiber based one. Just in a nutshell what I would try to implement, the moment I get to this item on my todo list. Although I would contact Soenke first, as he already has a lot of experience with fiber based IO. Regarding your problems with vibe, what is your particular problem with threads? Have you asked about your problems on http://news.rejectedsoftware.com/groups/rejectedsoftware.vibed/ ? Maybe they are easily solved? I don't use vibe multi-threaded currently, but if it does not work now, it seems that it is worked on. Also Soenke is usually glad about pull requests ;-) Best regards, Robert
Re: std.asio?
On Tue, 2013-03-12 at 11:07 +0100, Martin Drasar wrote: > It was related to blocking operations like readln stopping the event > loop. See > http://news.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/693/. > No real solution was found as this requires either the fiber support > in > std.concurrency or std.concurrency support in vibe.d. Your problem is exactly the reason why I would love async operation support in the standard library including a standard event loop. The moment you have to wait for something ( a second event loop or just a standard synchronous operation ) you are basically screwed. A single event loop which is capable of waiting for all kind of events (also std.concurrency messages from other threads) would solve the problem. Currently we have many different event loop implementations like: - boost::asio::io_service - libevent - glib/Qt - every other GUI toolkit out there seriously hampering interoperability between libraries. I hope it is possible to establish a standard event loop for at least D in the future, although I still have to check out whether this is realistic or if there are in fact serious technical differences between existing event loops due to different implementation goals. (libevent targeting high performance servers, might not be suitable for a GUI toolkit and vice versa, but I don't know.) Best regards, Robert
Bug 3274 not fixed but fixed?
Hi guys! In my research on what is the fastest and safest way to build D programs for dub, I found this: http://d.puremagic.com/issues/show_bug.cgi?id=3274 it is marked as WONTFIX, but I am not able to reproduce it. Is it fixed after all? Thanks! Best regards, Robert
Re: Need clarification on dmd symbol generation
TemplateInstance::enclosing, also does not get you the instantiating context, referring to the comment in the source code, I think for my tests it was null. importedFrom was no solution either. The only thing that worked for me was walking up with tinst and then use loc. This way you get the instantiating file. (Got that from printInstantiationTrace) I think it should be possible to use this found file name to find the module by iterating Module::modules, but I have not even bothered trying, because I felt there has to be some better way, unfortunately I also got no replies. At least it helps that I am not alone with this problem :-) Maybe it is not entirely unlikely that there is in fact no better way, as apart from "where do I put the instantiated template" and error messages there is really no need to know where the template got instantiated. Best regards, Robert
Re: Need clarification on dmd symbol generation
> Excited to see I am not the only one caring about this! :) > Module* can be found via tinst->scope->module, so it is pretty > straightforward. I have tried to use this and it _almost_ worked > but some symbols were still missing (I have mentioned example > with map and range before, can reduce test case if you are > interested). For me tinst->scope->module resolved to the module where the template is declared not the instantiating one, while tinst->loc.filename is the instantiating file. I am interested! > > Considering Kenji's explanation this seems to work as I have > initially understood. Then I need to reduce that case and see why > those std.range template symbols are not propagated to the top of > the chain. > > This is a major blocker for getting reliable and efficient > separate compilation and bugzilla issue references in topic is > just an observable side-effect. Getting reliable building is also quite important for dub, I don't want to work around dmd bugs (sometimes not even feasible), I would rather fix them :-)
Re: Need clarification on dmd symbol generation
On Wed, 2013-04-10 at 15:50 +0200, Dicebot wrote: > You now what? It worked. > > Before: > $ nm a.o | wc -l > 358 > > After: > $ nm a.o | wc -l > 68 > > I'll run a full test suite and do the pull request. > > Kenji you are my hero ;) :-( Still wrong output for my code. I commented on your pull request with more details.
Re: Allocatoin policy in Phobos - Was: Vote for std.process
I think you are right that phobos should avoid unnecessary allocations, if it does not affect maintainability/readability of code. I would suggest, instead of writing your own std.process, that you simply provide a pull request to the now to be approved one, this way you can prove your point that it is easy by already improving a part of the standard library. If your pull gets accepted, std.process could be referenced from a wiki page "how to minimize GC usage" for phobos contributions or something. Best regards, Robert
Re: Is there any plans to make working signals in D?
There is: http://wiki.dlang.org/Review_Queue It is currently blocked by: http://d.puremagic.com/issues/show_bug.cgi?id=8441 There is already a pull request for 8441, but it was not merged yet. As soon as 8441 gets fixed, I am going to finish up the implementation to make it ready for review. For an overview of fixes and improvements over the current implementation, simply search the forums for std.signals2. Best regards, Robert On Sun, 2013-04-14 at 11:06 +0400, Denis Shelomovskij wrote: > For "working signals" I suppose will be enough fixing of both Issue 9606 > [1] and Issue 9603 [2]. > > IMO, for the first issue we need weak references [3]. > IMO, for the second issue we need to make regular D objects on closures > [4] and fix Issue 9602 [5]. > > Any thoughts about my proposal to make signals working in D? Other > proposals? Any (approximate) period for [proposal parts] to be implemented? > > Also, does anybody think currently D has working signals and I'm just > slander in the title? > > P.S. > Also there is a proposal for new signals implementation without compiler > changes [6]. > > > [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606 > [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603 > [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151 > [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601 > [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602 > [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347 >
Re: Is there any plans to make working signals in D?
> Does it mean you disagree with proposed compiler changes and with the > idea we have to create weak reference functionality instead of > recreating it every time it is needed (beside of theoretical danger such > approach already showed it as a bad thing with `std.stdio.File` as I wrote)? > A weak reference could actually be implemented in the library relatively easy. ( I basically did it for std.signals2 ) But for std.signals a weak ref is not really enough, because ideally the slot gets removed if the target gets destroyed, not only set to null. Updating a collection on destruction of an object is not that easy as you pointed out (thank you for that), but I don't see how weak references would help there. But you just made me think: If it is ok that a signal does not release the memory for the slot immediately when the object gets destroyed but only on the next call to emit(), then the implementation would be much simpler ... Best regards, Robert
