Re: Mono-D v0.4.9 - Rough formatting capability
On 25.01.2013 21:34, Jacob Carlborg wrote: On 2013-01-25 20:00, alex wrote: I already suggested Rainer to make a native/non-native interface between VisualD and D_Parser - this will probably happen via COM or so.. and I dunno anything about that technique. I just can make sure that the parser library is fully stand-alone, only depending on .net internals. Let's see :) It should provide an C interface, then it can be connected to anything. COM is the natural choice when interfacing native code on Windows with C#. On other platforms it might be different. The semantic engine in Visual D is separated into another process and communicates with the IDE plugin through a number of commands, just using this interface: https://github.com/rainers/visuald/blob/master/vdc/ivdserver.d . This can easily be mapped to C calls. There's also an implementation of that interface using D_Parser (https://github.com/rainers/visuald/tree/master/vdc/abothe), but it isn't complete yet.
Re: Mono-D v0.4.9 - Rough formatting capability
On 2013-01-26 01:23, alex wrote: Why not wrap dmd's front-end? The problem with the DMD frontend is that it's not made to be used in on its own, like in an IDE. -- /Jacob Carlborg
Re: Mono-D v0.4.9 - Rough formatting capability
On Saturday, 26 January 2013 at 08:22:39 UTC, Rainer Schuetze wrote: On 25.01.2013 21:34, Jacob Carlborg wrote: On 2013-01-25 20:00, alex wrote: I already suggested Rainer to make a native/non-native interface between VisualD and D_Parser - this will probably happen via COM or so.. and I dunno anything about that technique. I just can make sure that the parser library is fully stand-alone, only depending on .net internals. Let's see :) It should provide an C interface, then it can be connected to anything. COM is the natural choice when interfacing native code on Windows with C#. On other platforms it might be different. The semantic engine in Visual D is separated into another process and communicates with the IDE plugin through a number of commands, just using this interface: https://github.com/rainers/visuald/blob/master/vdc/ivdserver.d . This can easily be mapped to C calls. There's also an implementation of that interface using D_Parser (https://github.com/rainers/visuald/tree/master/vdc/abothe), but it isn't complete yet. Concerning completion server...why not a completion server? :D - I mean, it'll be launched as soon as VisualD launches..and then you can pipe-through commands etc. to interact like it's done the mspdbsrv already. That's imho even easier than using COM + can be driven even as a web server..which would be a real dream then!
Re: Mono-D v0.4.9 - Rough formatting capability
On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote: Concerning completion server...why not a completion server? :D - I mean, it'll be launched as soon as VisualD launches..and then you can pipe-through commands etc. to interact like it's done the mspdbsrv already. That's imho even easier than using COM + can be driven even as a web server..which would be a real dream then! Some additional thoughts: All you need to specify at startup are include paths and some completion options or so. Then while editing, you either pass changes incrementally or push the entire document content to the server. The server parses that document then and updates the internal parse cache. These parse caches will be used for completion then. As you request e.g. the completion window to open or some tooltip info, you just pass the module name, the caret location and a command to the server - it'll answer then with all the items that shall be shown in the completion list or in the tooltip box. Furthermore, stuff like indenting and formatting could be interfaced, too - just push the document content, and it'll pass you back all changes to do OR the complete document. What do you think about this idea?
Re: Mono-D v0.4.9 - Rough formatting capability
On 26.01.2013 13:09, alex wrote: On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote: Concerning completion server...why not a completion server? :D - I mean, it'll be launched as soon as VisualD launches..and then you can pipe-through commands etc. to interact like it's done the mspdbsrv already. That's imho even easier than using COM + can be driven even as a web server..which would be a real dream then! Some additional thoughts: All you need to specify at startup are include paths and some completion options or so. Then while editing, you either pass changes incrementally or push the entire document content to the server. The server parses that document then and updates the internal parse cache. These parse caches will be used for completion then. As you request e.g. the completion window to open or some tooltip info, you just pass the module name, the caret location and a command to the server - it'll answer then with all the items that shall be shown in the completion list or in the tooltip box. Furthermore, stuff like indenting and formatting could be interfaced, too - just push the document content, and it'll pass you back all changes to do OR the complete document. What do you think about this idea? That's actually what the Visual D semantic server process does. Syntax highlighting and indenting are done in the plugin, though. These don't need anything more than lexing so far and must be fast. Specifying import paths and compile options isn't so easy, because you can have different options for different projects in the solution, meaning the same file might be even used with different settings. That's also one of the points where integration of D_Parser is kind of brittle.
Re: Mono-D v0.4.9 - Rough formatting capability
On Saturday, 26 January 2013 at 12:28:11 UTC, Rainer Schuetze wrote: On 26.01.2013 13:09, alex wrote: On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote: Concerning completion server...why not a completion server? :D - I mean, it'll be launched as soon as VisualD launches..and then you can pipe-through commands etc. to interact like it's done the mspdbsrv already. That's imho even easier than using COM + can be driven even as a web server..which would be a real dream then! Some additional thoughts: All you need to specify at startup are include paths and some completion options or so. Then while editing, you either pass changes incrementally or push the entire document content to the server. The server parses that document then and updates the internal parse cache. These parse caches will be used for completion then. As you request e.g. the completion window to open or some tooltip info, you just pass the module name, the caret location and a command to the server - it'll answer then with all the items that shall be shown in the completion list or in the tooltip box. Furthermore, stuff like indenting and formatting could be interfaced, too - just push the document content, and it'll pass you back all changes to do OR the complete document. What do you think about this idea? That's actually what the Visual D semantic server process does. Lol. Syntax highlighting and indenting are done in the plugin, though. These don't need anything more than lexing so far and must be fast. Isn't there any integrated lexing done by the VS editor component? MD as well as #develop provide simple syntax definitions. But well, semantic type highlighting..yeah, this could be an issue - whereas..this process takes only 1 ms or so in D-IDE, so this shouldn't be a problem. Specifying import paths and compile options isn't so easy, because you can have different options for different projects in the solution, meaning the same file might be even used with different settings. That's also one of the points where integration of D_Parser is kind of brittle. This wouldn't be a problem: There already is a strict separation of global (phobos, tango, vibe.d) and local (project, project-specific include) module sets in the parse cache. As I already said, changes to single documents could be passed to a document 'mirror' in the completion server immediately. Wait, the same file might be used with different settings? Hehe, there actually are no settings for parsing and code completion. Anyway, why should two projects make use of two files? Even if, this wouldn't be any reason to turn mad - the AST was just stored in two parse caches then, so no problem at all :)
Re: @property - take it behind the woodshed and shoot it?
On 1/25/2013 10:06 PM, Mehrdad wrote: Walter, that's not how TLS variables are generally implemented in C/C++. Since I implemented them, I know how they work. They're *normal* variables, placed in a special section of the executable, which is automatically switched in and out on every context switch by the OS. This is not necessarily true at all. It isn't for OSX, for example, and there's nothing in the semantics of TLS which preclude calling a function.
Re: @property - take it behind the woodshed and shoot it?
On Saturday, 26 January 2013 at 07:25:24 UTC, Walter Bright wrote: On 1/25/2013 10:06 PM, Mehrdad wrote: Walter, that's not how TLS variables are generally implemented in C/C++. Since I implemented them, I know how they work. I wasn't being pedantic. That's why I said generally, not always. Obviously you can implement things a million different ways... They're *normal* variables, placed in a special section of the executable, which is automatically switched in and out on every context switch by the OS. This is not necessarily true at all. It isn't for OSX, for example, and there's nothing in the semantics of TLS which preclude calling a function. Again, I didn't say they're necessarily true either, hence why I mentioned Linux and Windows specifically. OS X is really the odd one out here, not Windows or Linux. But you missed my point, which was, yes, a lot of things COULD contain function calls. Even the two lines int i = 0; i++; COULD contain a function call, but how is that in any shape or form relevant to the discussion about @property in any way? Generally, it isn't a function call, and as far as the code is concerned, it isn't a function call. The fact that you may have happened to implement something as a function call doesn't mean anything with regards to the difference between a function call and a direct access for the _programmer_.
Re: Incorporating D
26-Jan-2013 04:42, H. S. Teoh пишет: On Fri, Jan 25, 2013 at 11:32:19PM +0100, Szymon wrote: Ah, perfectly clear now. Thanks guys. At one point I though maybe it was about move semantics but it indeed about something much more fundamental. And indeed surprising coming from C++. [...] When moving to D, one thing to keep in mind is that you should not expect C/C++ struct and D struct to behave the same way, because they do not. In D, a struct is a value type, and basically behaves like a glorified int. This means assignment with = (shallow-)copies the struct, structs are allocated on the stack by default (unless you explicitly use new), etc.. Be aware that using struct ctors/dtors is fraught with peril; the simplest cases do work, but there are some bugs with complicated dtors and some unexpected behaviour with @disable ctors. If you need a complicated dtor, chances are you want to be using a class anyway. Same goes for postblit ctors (the analogue of copy ctors): there are some bugs related to this, and IMO, if you need to do complicated stuff in a postblit, you should just use a class. In general postblit/dtor are working but I wouldn't recommend using them in complex code (least you want to file a bug report) like with statements, or array-literals [ Struct(...), Struct(...), Struct(...)], and of course built-in associative arrays(!). Another thing of importance is that pass-by-value is automated to move (simple bitwise-copy) where applicable as D structs can't have internal references. And you don't have to define move constructor or rely on sombody to define it. In D, a class is a reference type, which means they are always passed by reference, and assignment with = only copies the reference, NOT the object. By default, they are allocated on the heap (unless you use emplace), and generally, ctors and dtors work in a much more predictable and stable way. (But be aware that dtors may not run when you expect, because the GC may not collect the object immediately after it's out of use.) Class objects are not deep-copied unless you provide a method to do that yourself. In summary, if you want something that behaves like an int, but just happens to have a couple of extra fields, use a struct. If you want complex behaviours like ctors, dtors, copy/cloning semantics, polymorphism, etc., spare yourself the pain and just use a class. (It *is* possible to pull some tricks along these lines with structs, but like I said, there is a risk of running into some bugs in that area, so it's best to steer clear until these issues have been fixed.) T -- Dmitry Olshansky
Re: Incorporating D
26-Jan-2013 03:48, Rob T пишет:
On Friday, 25 January 2013 at 22:29:44 UTC, Adam D. Ruppe wrote:
On Friday, 25 January 2013 at 22:22:44 UTC, Szymon wrote:
So structs in D are always passed by-value? That is unfortunate...
It has both pointers and ref but they both only work with lvalues,
regardless of const:
struct S {}
void test(const ref S s) {}
void test2(const S* s) {}
S getS() { return S(); }
void main() {
S s;
test(s); // ok
test2(s); // ok
test(getS()); // not ok (line 12)
test2(getS()); // not ok (line 13)
}
test.d(12): Error: function test.test (ref const(S) s) is not callable
using argument types (S)
test.d(12): Error: getS() is not an lvalue
test.d(13): Error: getS() is not an lvalue
It should be mentioned that there's a solution of sorts, but it is a
pain to have to do and does not scale up when you have multiple ref
arguments.
void test(const ref S s)
{
// implementation
...
return;
}
void test(const S s)
{
test( s ); // calls test(const ref S s)
return;
}
void test(const S s){ return test(s); }
D is not Java and allows returning void functions directly ;)
--
Dmitry Olshansky
Re: @property - take it behind the woodshed and shoot it?
26-Jan-2013 09:04, deadalnix пишет:
On Friday, 25 January 2013 at 19:59:59 UTC, Andrei Alexandrescu wrote:
1. Syntactic and semantic implications of properties that return
callable entities
I don't understand why this is a special case in the first place. It
should behave just like a variable of the same type, period.
C has no methods so the syntax object.method does not apply to it.
In C++, object.method is probably the oddest construct in the entire
language: it returns a type that exists but has no name, is not
expressible syntactically, is not first class (one can't assign
object.method to a variable), and has only two allowed operations:
take address or apply the function call operator (). Various C++
implementations have extensions that fix this.
Both Walter and I consider these serious lapses in language design.
Two of the most accessible elements of syntax do things of
considerably low interest and use. I hope I now clarified why I have a
dim view of arguments that - implicitly or explicitly - assume the C
or C++ behavior in this area is an example to follow on technical
grounds. (Clearly, familiarity is a much better argument.)
Javascript or C# have solved that issue with C like language nicely.
That is why I propose to do the same here (and considering how much C#
has been mentioned here, it sound like a serious option). I know that
Javascript is a poorly designed language, but on that very specific
topic most people agree that was has been done at the time was pure genius.
It removes the weird C/C++ object that have no expressible type, and
simplify the situation. Additional benefice is that funName now behave
the same in all situation, which is also a simplification of the situation.
2. I have tried to add @property appropriately in Phobos, in
particular for ranges:
struct SomeRange {
@property bool empty();
@property ref T front();
void popFront();
}
There's more @property to be seen with save and back.
Subjectively that just didn't work well for me. It adds clutter to an
otherwise simple and straightforward API, and penalizes usage for
benefits that I could never reap. I understand how some people are
glad to put that in everywhere, and find meaning in requiring parens
with popFront and popBack but not the others. Yet for me it was
liberating (see 1 above too) I could just write r.popFront without
the parens and have it do its deed. It is the right semantics for a
simple syntax.
If you ask me, I think property have been abused in range design. Many
ranges properties really shouldn't be properties.
Additionally, this kind of boilerplate can easily be written by
automated tools. Java or C# are very verbose, but it is very efficient
to write program in them, as the tooling to a great job for you.
Automated tooling is admitting a defeat if we talk about expressive
languages. Java was designed with automatic code manipulation in mind
and even with todays proliferation of generators it's a pain to work with.
TL;DR code is written once and read many times.
--
Dmitry Olshansky
Re: @property - take it behind the woodshed and shoot it? - writefln
please give us your own code and preferred solution to compile-time formatting string checking. I am not interested in formatting at all. I wrote about the general problem to incorporate expectable many DSL's into one big source base, as D is intended to serve large scale coding. And what's the solution, for you? Using strings as DSL is somewhat common in D. As for DSL, well, I have a parser generator project here (https://github.com/PhilippeSigaud/Pegged), and I recently added the capacity to add new rules to a grammar at runtime and modify the resulting parse tree. I also used the existent, but unused macro keyword in D to get source code that can define its own subsequent grammar and parse tree transformations. Oh, and grammars can call one another, so adding a new sublanguage to a parent language is doable (I use this from time to time). I still have weeks fo work on this to have it reach the level I want, but I did not hit any wall up to now. So adding clean-looking DSL can be done in D, I think. I am sure that your stab at it does not show any intent to approach the general problem. No, indeed :) Since it's a recurring question here, I just showed it could be done. It's also a simple example of what can be done with D meta-programming capacities.
Re: @property - take it behind the woodshed and shoot it?
On Saturday, 26 January 2013 at 08:29:40 UTC, Dmitry Olshansky wrote: Automated tooling is admitting a defeat if we talk about expressive languages. Java was designed with automatic code manipulation in mind and even with todays proliferation of generators it's a pain to work with. TL;DR code is written once and read many times. Using tooling is admitting defeat ? That is very misplaced pride (and not even an argument). And if you think that verbose code is less readable, think twice, or follow both links : http://code.jquery.com/jquery.js http://code.jquery.com/jquery.min.js No doubt the less verbose one is more readable !
Re: @property - take it behind the woodshed and shoot it?
On 1/25/2013 11:52 PM, Mehrdad wrote: The fact that you may have happened to implement something as a function call doesn't mean anything with regards to the difference between a function call and a direct access for the _programmer_. I.e. the difference is purely a contrivance, which was my point.
Re: @property - take it behind the woodshed and shoot it?
On Saturday, 26 January 2013 at 09:04:47 UTC, Walter Bright wrote: On 1/25/2013 11:52 PM, Mehrdad wrote: The fact that you may have happened to implement something as a function call doesn't mean anything with regards to the difference between a function call and a direct access for the _programmer_. I.e. the difference is purely a contrivance, which was my point. Yes, that the whole point of abstraction. It happen that variables and functions are both very useful ones.
Re: @property - take it behind the woodshed and shoot it?
26-Jan-2013 12:57, deadalnix пишет: On Saturday, 26 January 2013 at 08:29:40 UTC, Dmitry Olshansky wrote: Automated tooling is admitting a defeat if we talk about expressive languages. Java was designed with automatic code manipulation in mind and even with todays proliferation of generators it's a pain to work with. TL;DR code is written once and read many times. Using tooling is admitting defeat ? That is very misplaced pride (and not even an argument). There is no pride. Requiring a separate tool to generate code even in simple cases is a defeat. Using tools is fine to refactor, navigate etc. but not to generate boilerplate as in the end it still has to be read, modified and fitted with the rest of code. Boilerplate generally has no place in code at all if we can help it. And if you think that verbose code is less readable, think twice, or follow both links : http://code.jquery.com/jquery.js http://code.jquery.com/jquery.min.js No doubt the less verbose one is more readable ! Obfuscation/minification and boilerplate is not the same. And I bet the second example is the same exact code so you missed the point completely. -- Dmitry Olshansky
Re: Incorporating D
On Friday, 25 January 2013 at 23:24:54 UTC, Andrei Alexandrescu wrote: Thank you for asking. We have been strongly focused on quality improvement since last year but judging from this thread we need to work more on it (and the derived community sentiment). Andrei And that is true, during 2012 and by now 1495 bug fixed and closed: http://d.puremagic.com/issues/buglist.cgi?chfieldto=Nowquery_format=advancedchfield=bug_statuschfieldfrom=2012-01-01bug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDcomponent=DMDproduct=D That is just so Awesome! Great thanks to everybody involved! The bad news is there are still some TDPL bugs: http://d.puremagic.com/issues/buglist.cgi?keywords=tdplquery_format=advancedkeywords_type=allwordsbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=DMDproduct=D These probably would require more attention because TDPL is the _only_ printed source of the language. Not so big amount although, so using D per TDPL looks pretty safe. Oleg.
Re: @property - take it behind the woodshed and shoot it?
Am Fri, 25 Jan 2013 21:38:44 -0800 schrieb Walter Bright newshou...@digitalmars.com: On 1/25/2013 2:14 PM, Jonathan M Davis wrote: A property function is fundamentally different from a normal function by its very nature, not just by its call syntax. I would have agreed with you on that for years, simply taking its veracity as an axiom, but lately I am not convinced at all of that assertion. I suspect the differences between a property, field, and method are purely contrivance. For example, even accessing a global variable isn't straightforward, if you look under the hood. If it's in a DLL or TLS, there may be a function call in there that is non-trivial. Although variable access might be implemented as a non-trivial function calls everyone tries to make these as fast as possible. Think of PLT/GOT or the TLS register on ARM processors. And this is the difference between variable/property and function: Access to the former has to be 'fast'. There's no real definition of fast in this case, but I doubt an O(n^2) implementation of TLS or variable access in general would be acceptable to anyone.
Re: @property - take it behind the woodshed and shoot it?
On 24.1.2013 9:34, Walter Bright wrote:
This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
Perhaps we should revert to a simple set of rules.
1. Empty parens are optional. If there is an ambiguity with the return
value taking (), the () go on the return value.
2. the:
f = g
rewrite to:
f(g)
only happens if f is a function that only has overloads for () and (one
argument). No variadics.
3. Parens are required for calling delegates or function pointers.
4. No more @property.
Maybe one possible issue to note. I am sorry if someone already noted
this but I didn't saw it so here it is.
In druntime's object_.d AssociativeArray has:
@property size_t length() { return _aaLen(p); }
By removing @property typeof([].length) is no longer uint or ulong. It
would change into uint() or ulong(). And not just for length, but any
other properties type's would change.
I think that this is one big possible code breaker for everyone that
uses something similar to the following:
typeof([].length) l = [].length;
Maybe I am wrong but my personal opinion is that code like this should
compile because semantically length is a property and the fact that it
is a functions is just a implementation detail.
Re: Incorporating D
Am Fri, 25 Jan 2013 22:38:51 +0100 schrieb Jonathan M Davis jmdavisp...@gmx.com: On Friday, January 25, 2013 22:33:14 q66 wrote: D's GC does not have serious problems. The only issue is controversial status of GC. D's GC has inherent issues with false positives, sometimes freeing memory that you don't really want freed, causing (sometimes hidden) bugs that are pretty much impossible to debug. I've _never_ heard of it freeing something when it shouldn't. I've seen that when porting GDC. Usually happens if the GC fails to scan the stack or more often it misses some TLS ranges. Never saw that with dmd though. IIRC toStringz is also dangerous. You have to make sure that the C library does not store the pointer or also store it manually so the GC can find it. (This is not different from passing other C/D pointers, but with toStringz it's easy to miss).
Re: Incorporating D
On 1/26/2013 1:41 AM, Johannes Pfau wrote: IIRC toStringz is also dangerous. You have to make sure that the C library does not store the pointer or also store it manually so the GC can find it. (This is not different from passing other C/D pointers, but with toStringz it's easy to miss). That's not a bug in the GC, though.
Re: Incorporating D
On Saturday, January 26, 2013 10:41:46 Johannes Pfau wrote: Am Fri, 25 Jan 2013 22:38:51 +0100 schrieb Jonathan M Davis jmdavisp...@gmx.com: On Friday, January 25, 2013 22:33:14 q66 wrote: D's GC does not have serious problems. The only issue is controversial status of GC. D's GC has inherent issues with false positives, sometimes freeing memory that you don't really want freed, causing (sometimes hidden) bugs that are pretty much impossible to debug. I've _never_ heard of it freeing something when it shouldn't. I've seen that when porting GDC. Usually happens if the GC fails to scan the stack or more often it misses some TLS ranges. Never saw that with dmd though. IIRC toStringz is also dangerous. You have to make sure that the C library does not store the pointer or also store it manually so the GC can find it. (This is not different from passing other C/D pointers, but with toStringz it's easy to miss). Which is why the toStringz documentation points that out. The GC can only see what's referred to in the D code, not C code, so you have to make sure that the D code retains a reference to any pointers passed into C code or risk the GC thinking that it's okay to free it. But there really isn't any way around that, and it's completely different from the GC incorrectly thinking that a pointer was not referenced anywhere in D code and freeing it. - Jonathan M Davis
Re: dmd json file output
On 23.01.2013 06:42, Andrei Alexandrescu wrote:
On 1/22/13 3:36 PM, Walter Bright wrote:
On 1/22/2013 11:46 AM, Andrei Alexandrescu wrote:
On 1/22/13 2:48 AM, Walter Bright wrote:
On 1/21/2013 10:56 PM, ric wrote:
Would it be reasonable to put an option whether to produce the (too)
verbose
json output or the minimal one?
I'd rather we make a decision.
Verbose should probably be it.
Rationale?
You can always filter out the verboseness with a simple program, but you
can't add missing information.
If the efficiency of generating json ever comes up, _then_ it's worth
looking into an option that produces less verbose output directly. For
now be verbose and let downstream tools filter it out.
Andrei
I updated dmd from github and had a look at the current json output:
it's horrible. Below is a random example of a simple function.
- the function parameters are listed three times with different type
information
- originalType seems to be always shown, even though it probably was
meant to if it is different from type
- if the parameter identifiers are listed separately anyway, they should
not be part of the type while the types do not have to be repeated n the
actual parameter list
- package and module are specified inconsistently, sometimes as an array
of strings, sometimes in dot-notation, sometimes not at all.
- types are sometimes shown expanded, sometimes not (e.g. string)
- template instantiations from imported source files are listed
- functions and template instantiations that are only used at compile
time are listed
- I appreciate that some missing information has been added, like
imports and storage class
- renamed imports don't show the original module name
- functions implemented through template mixins are not listed
- surprisingly the average output has only become about 10 times larger
for a medium sized project like Visual D (73 MB instead of 8 MB). Having
only std.json available for reading it, I suspect it will definitely
have an impact on IDE performance, though.
I understand that most of these issues are QOI issues but it also seems
that there is also a shift in the target usage of the JSON output. It
was a means for source code browsing with output similar to generated di
files, while it is now showing everything written into object files
similar to debug info. Some of this can easily be filtered out (e.g.
template instance) but not all (e.g. functions from other modules only
used in CTFE).
So I think that we should remove excessive bloat (e.g. always specify
package and module lists in dot notation), make output more consistent
and avoid listing the same type again and again. If a type is specified
by its mangled name in declarations, add it to a dictionary at the end
of the json file in its full verbosity. (I agree core.demangle does not
help you if you want to do anything more than just getting the pretty
type string). Please be aware that you will have to document the JSON
type format in addition to the existing name mangling, though.
Rainer
JSON output for
void setAttribute(Element elem, string attr, string val);
dmd 2.061:
{
name : setAttribute,
kind : function,
protection : public,
type : void(Element elem, string attr, string val),
line : 37}
,
dmd 2.062alpha:
{
name : setAttribute,
kind : function,
loc : {
line : 37
},
module : {
name : xmlwrap,
kind : module,
package : [
visuald
],
prettyName : visuald.xmlwrap
},
type : {
kind : function,
pretty : void(Element elem, string attr, string val),
returnType : {
kind : void,
pretty : void
},
parameters : [
{
name : elem,
type : {
kind : class,
pretty : std.xml.Element
}
},
{
name : attr,
type : {
kind : darray,
pretty : string,
elementType : {
kind : char,
pretty : immutable(char),
modifiers : immutable
}
}
},
{
name : val,
type : {
kind : darray,
pretty : string,
elementType : {
kind : char,
pretty : immutable(char),
modifiers : immutable
}
}
}
]
},
originalType : {
kind : function,
pretty : void(Element elem, string attr, string val),
returnType : {
kind : void,
pretty : void
},
parameters : [
{
name : elem,
type : {
kind : identifier,
pretty : Element,
idents : [],
rawIdentifier : Element,
identifier : Element
}
},
{
name : attr,
type : {
kind : identifier,
pretty : string,
idents : [],
rawIdentifier : string,
identifier : string
}
},
{
name : val,
type : {
kind : identifier,
pretty : string,
Re: Incorporating D
Am Sat, 26 Jan 2013 02:19:02 -0800 schrieb Jonathan M Davis jmdavisp...@gmx.com: IIRC toStringz is also dangerous. You have to make sure that the C library does not store the pointer or also store it manually so the GC can find it. (This is not different from passing other C/D pointers, but with toStringz it's easy to miss). Which is why the toStringz documentation points that out. The GC can only see what's referred to in the D code, not C code, so you have to make sure that the D code retains a reference to any pointers passed into C code or risk the GC thinking that it's okay to free it. But there really isn't any way around that, and it's completely different from the GC incorrectly thinking that a pointer was not referenced anywhere in D code and freeing it. - Jonathan M Davis Yes, I just wanted to point out a common source for such bugs, it's not the GC's fault. It's great that the documentation of toStringz mentions that issue. What I meant is most of the time we use toStringz() like this: string str; c_function(str.toStringz()); This is only valid if c_function doesn't store the pointer, but newbies might miss that and just copy this nice looking example code for other c functions. There's nothing we can do about that though, interfacing to C just is a little bit dangerous.
Re: Incorporating D
As he apparently is on Windows, you can only do this with a D DLL, which are likely to be a PITA (but at least they should work unlike on un*x); you can't really link D object files and C/C++ object files together, as on win32 OMF is used Couldn't you work around that by compiling your D code with GDC/MinGW and the C++ code with MinGW?
Re: @property - take it behind the woodshed and shoot it? - writefln
On 01/26/13 08:50, Philippe Sigaud wrote: please give us your own code and preferred solution to compile-time formatting string checking. I am not interested in formatting at all. I wrote about the general problem to incorporate expectable many DSL's into one big source base, as D is intended to serve large scale coding. And what's the solution, for you? Using strings as DSL is somewhat common in D. I think his point was that inventing a custom dsl for everything does not scale. And he's of course right. Having one, or at most a few, common std dsls, plus ability do define custom ones is enough. But the std ones must be able to handle 95%+ of cases. So that everyone does not need to learn a set of custom per-site and/or per-project dsls. BTW, the std compile-time string formatting dsl is not only checkable, but can relatively easily be parsed at CT; the compiler will then do the rest. So there's really no point in using such a CT checker - if the string can be checked then it can also be handled directly, skipping any runtime parsing overhead completely. As for DSL, well, I have a parser generator project here (https://github.com/PhilippeSigaud/Pegged), and I recently added the capacity to add new rules to a grammar at runtime and modify the resulting parse tree. I also used the existent, but unused macro keyword in D to get source code that can define its own subsequent grammar and parse tree transformations. Oh, and grammars can call one another, so adding a new sublanguage to a parent language is doable (I use this from time to time). I still have weeks fo work on this to have it reach the level I want, but I did not hit any wall up to now. So adding clean-looking DSL can be done in D, I think. Yes, this is possible, and desirable, to avoid polluting the main language with certain features. However it's likely not enough, as there are aspects of D which make pure macro/dsl solutions not as simple as they could be (consider static-foreach). Your inline, parse-time, grammar extensions only work when the parser runs at CT, so the performance issues remain, right? Still, sounds interesting; and could be enough to explore the trickier cases and identify further problems. Must find time to play with it. Is that feature already in the repo? artur
Re: Incorporating D
On 26.01.2013 11:40, Johannes Pfau wrote:
Yes, I just wanted to point out a common source for such bugs, it's not
the GC's fault. It's great that the documentation of toStringz mentions
that issue. What I meant is most of the time we use toStringz() like
this:
string str;
c_function(str.toStringz());
This is only valid if c_function doesn't store the pointer, but newbies
might miss that and just copy this nice looking example code for other
c functions. There's nothing we can do about that though, interfacing
to C just is a little bit dangerous.
It is even dangerous if it is only used temporarily during that function
call, but copied elsewhere in the C heap and cleared on the stack:
struct param_struct { const char* name; };
void c_function(const char*p)
{
param_struct* ps = new param_struct;
ps-name = p;
p = 0;
doSomething(ps);
delete ps;
}
Imagine a garbage collection while executing doSomething...
Re: @property - take it behind the woodshed and shoot it? - writefln
On 01/26/13 11:46, Artur Skawina wrote: identify further problems. Must find time to play with it. Is that feature already in the repo? Found it. Unfortunately the old compiler here can't handle newer D features and I can't really upgrade right now, so playing with pegged will have to wait. artur
Re: Incorporating D
On Saturday, 26 January 2013 at 02:51:41 UTC, Namespace wrote: We better get this right and not hurry about this. I will open a new, separate thread about this tomorrow. Seems to me more appropriate. Then we can discuss about this important but missing feature in detail. http://forum.dlang.org/thread/nirfuenixutsbgyrc...@forum.dlang.org#post-nirfuenixutsbgyrcsla:40forum.dlang.org
Re: Make dur a property?
On 2013-01-25 20:27, Nick Sabalausky wrote: I agree in principle, but unfortunately return zis variable getters are often needed because no major language (that I know of) offers any other way to create data that's privately-writable and publicly-read-only - a very common need. Ie, that's the something that is wrong already: the lack of a simple built-in The public can only read this, but I can R/W it. to obviate an extremely common idiom. In Ruby one would do: class Foo attr_reader :foo end This would create a getter and an instance variable. Internally one can write directly do the instance variable, or create a setter: class Foo attr_reader :foo private def foo= (value) # code end end The equal sign indicates the method is a property. Not that attr_reader is not a language feature, it's implemented in the core library. There are also functions available for getter and both getter and setter. In D, I would like to see something like this: @property(get, set) int a; @property(get) int b; @property(set) int c; @property int d; // same as a This would create a getter and/or setter and an instance variable. One could also experiment with the protection attributes like this: public @property(get, protected set) int a; One way could affect the instance variable, the other way to affect the getter/setter implementation. -- /Jacob Carlborg
Re: Mac OS installer
On 2013-01-26 03:50, Elias Zamaria wrote:
I have GCC and I have used it to compile C programs. Anyway, I tried
typing dmd at the terminal and it tells me I have version 2.061. I
have no idea how that got there or if the whole thing got installed.
Hehe, try a Hello World application:
// main.d
import std.stdio;
void main ()
{
writeln(Hello World);
}
Compile with:
$ dmd main.d
Run with:
$ ./main
--
/Jacob Carlborg
Re: Mobile app support?
On Saturday, 26 January 2013 at 05:33:17 UTC, Oleg Kuporosov wrote: On Friday, 25 January 2013 at 19:37:43 UTC, Johannes Pfau wrote: That's it for Android. For ARM in general, gdc support is quite OK. There are 10 failures in the compiler test suite which are really arm specific bugs. Not much work has been done on druntime phobos ARM supprt though. I know that at least the GC TLS is working on ARM/Glibc. Good overview and job Johannes, thanks! Just a note, may be somebody are not aware. Even DMD can be used to play with Android! There are already Intel based smartphones in Europe and Asia, like Motorola RAZR I and some telcos-branded. Atom and Core tablets will be there soon starting with Windows 8 and then I hope Android too. It may simplify RT porting efforts a lot. Oleg. I'm typing this on an Intel AZ210 right now, branded as an Orange San Diego. It would be really cool to be able to write apps in D for it!
Re: Incorporating D
On 2013-01-25 23:00, Rob T wrote: In fact I find that C++ IDE and editor support is no better, and fails often due to the near impossible nature of correctly parsing through C++ code. I think Xcode on Mac OS X is really good. It uses Clang for parsing the code, so if the IDE can't parse the code the compiler can't either. -- /Jacob Carlborg
Re: Incorporating D
On 2013-01-25 21:45, Szymon wrote: 3) Is it possible to use D on iOS? The short answer is, no. The longer more detailed answer is, DMD cannot output ARM code. That means you need to use LDC or GDC. Don't know how good they work, also I don't know the status of the runtime on ARM. Then you need to somehow integrate the D compiler in the iOS tool chain. Except from actually be able to compile for iOS you need some way to integrate with Objective-C, if you want to do anything useful. For that you have three options: 1. The Objective-C runtime functions are implemented in standard C which D can call and link to. It becomes very tedious very fast using this approach. 2. Use the Objective-C runtime functions via a bridge that handles all type conversions and similar automatically. This causes code bloat due to template and virtual methods that cannot be optimized away. On Mac OS X we're talking about 60MB for a Hello World application. 3. Make D ABI compatible with Objective-C, i.e. extern (Objective-C). Michel Fortin has created a fork of DMD that implements this. He has released an alpha version of this fork which do work. Unfortunately the code hasn't been update for two to three years. The most correct approach would be number three. Objective-C bridge: http://www.dsource.org/projects/dstep D with support for Objective-C: http://michelf.ca/projects/d-objc/ -- /Jacob Carlborg
Re: @property - take it behind the woodshed and shoot it?
On 2013-01-25 22:20, Andrei Alexandrescu wrote:
That's right with the amendment that we're looking for a solution, not
pushing one. Even the title of the thread is a question.
Clearly properties are good to have. In an ideal world we wouldn't need
a keyword for them and we'd have some simple rules for determining
property status (especially when it comes to writes). If syntactic help
is necessary, so be it. We want to make the language better, not worse.
It's always possible to avoid keywords in favor of syntax. Example:
Declaring a getter:
int foo {}
Just as a regular function declaration but without the parentheses.
Declaring a setter:
void foo= (int value) {}
Append an equal sign to the function name.
--
/Jacob Carlborg
Re: @property - take it behind the woodshed and shoot it?
On 2013-01-25 19:00, Rob T wrote: Why was a partial implementation of an experimental half-backed idea released into the wild? It seems just to be how things are done in the D community. Another recent example of this is the UDA that popped up and got implemented from nowhere. -- /Jacob Carlborg
Last weekend before submissions proposals deadline
Hello, This is the last weekend before the submission deadline on Monday. This is the time to act! Remember, at this time we only need the title, abstract, and bio - no article or slides. If you do have a proposal in mind but extraordinary circumstances prevent you from making the deadline, please let us know. Thanks, Andrei
Re: @property - take it behind the woodshed and shoot it? - writefln
On 1/26/13 2:50 AM, Philippe Sigaud wrote: As for DSL, well, I have a parser generator project here (https://github.com/PhilippeSigaud/Pegged), and I recently added the capacity to add new rules to a grammar at runtime and modify the resulting parse tree. I also used the existent, but unused macro keyword in D to get source code that can define its own subsequent grammar and parse tree transformations. Oh, and grammars can call one another, so adding a new sublanguage to a parent language is doable (I use this from time to time). I still have weeks fo work on this to have it reach the level I want, but I did not hit any wall up to now. So adding clean-looking DSL can be done in D, I think. I am sure that your stab at it does not show any intent to approach the general problem. No, indeed :) Since it's a recurring question here, I just showed it could be done. It's also a simple example of what can be done with D meta-programming capacities. Looking forward to your talk? :o) Andrei
On the subject of properties, and possibility of having them in the library
While the storm raged, I decided to try implementing properties as library
types. I encountered a few obstacles, which I will outline here.
First, my intended syntax:
class A {
int _n;
Property!(
() = _n,
value = _n = value
) n;
}
Property would then be a struct, with operators and functions defined as
required, copying disabled, and of course alias this.
Now, the obstacle here is I can't refer to _n in those lambdas. Why not?
I'm guessing the struct has no context member, and the lambdas don't
because the class is not yet instantiated. Could this be fixed? I think
so, and I think this is a feature with benefits beyond simple properties.
This library solution would not be able to do everything a language
solution could. Amongst those, typeof(property) would return
Property!(..., ...). Just as important, this would not work:
auto a = foo.property;
, because the struct's postblit is marked @disable. Perhaps alias this
should be attempted in such a situation?
--
Simen
Re: Incorporating D
On 1/26/13 4:23 AM, Oleg Kuporosov wrote: On Friday, 25 January 2013 at 23:24:54 UTC, Andrei Alexandrescu wrote: Thank you for asking. We have been strongly focused on quality improvement since last year but judging from this thread we need to work more on it (and the derived community sentiment). Andrei And that is true, during 2012 and by now 1495 bug fixed and closed: http://d.puremagic.com/issues/buglist.cgi?chfieldto=Nowquery_format=advancedchfield=bug_statuschfieldfrom=2012-01-01bug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDcomponent=DMDproduct=D That is just so Awesome! Great thanks to everybody involved! The bad news is there are still some TDPL bugs: http://d.puremagic.com/issues/buglist.cgi?keywords=tdplquery_format=advancedkeywords_type=allwordsbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=DMDproduct=D These probably would require more attention because TDPL is the _only_ printed source of the language. Not so big amount although, so using D per TDPL looks pretty safe. Also, http://dlang.org/bugstats suggests (red line) a downward trend of bugs reported and unfixed. I also played a bit with the chart generator and plotted open vs. resolved bugs for the past 365 days: http://goo.gl/OX9bo. It seems we're consistently reducing net opened issues since November. Andrei
Re: @property - take it behind the woodshed and shoot it?
On 2013-01-26 02:48, Jonathan M Davis wrote:
: works works with any function attribute, as does {}.
And even for user defined attributes :)
--
/Jacob Carlborg
Re: @property - take it behind the woodshed and shoot it?
On 2013-01-26 08:52, Mehrdad wrote: Again, I didn't say they're necessarily true either, hence why I mentioned Linux and Windows specifically. OS X is really the odd one out here, not Windows or Linux. They can be implemented as a function call on (at least) Linux as well. It's depends on which model is used. Which model is used then depends on various things like who the compiler is able to optimize and dynamic libraries are involved or not. Mac OS X chose the easiest way out and implemented only one mode. A model that works in all cases, and that is a function call. -- /Jacob Carlborg
Re: On the subject of properties, and possibility of having them in the library
Reason why library properties are not that usable is simple: typeof(A._n) must be same as typeof(A.n) or this is not really a property. Please take a look at examples and arguments in wiki: http://wiki.dlang.org/Property_Discussion_Wrap-up
Re: @property - take it behind the woodshed and shoot it?
On 2013-01-25 17:37, eles wrote:
One more thing (see also this:
http://www.25hoursaday.com/CsharpVsJava.html#properties)
In order to avoid properties throwing exceptions, maybe is wise
to impose getters and setters to be nothrow.
Why? Because code like this (C#) seems a bit unnatural:
try{
myClock.Hours = 28; /* setter throws exception because 28 is
an invalid hour value */
myClock.Minutes = 15;
myClock.Seconds = 39;
}catch(InvalidTimeValueException itve){
/* figure out which field was invalid and report error */
}
One of the points of properties is to have a field with validation. To
indicate the validation failed you would throw an exception. Therefore
properties need to be able to throw exceptions.
--
/Jacob Carlborg
Re: @property - take it behind the woodshed and shoot it?
On Saturday, 26 January 2013 at 13:21:37 UTC, Jacob Carlborg
wrote:
It's always possible to avoid keywords in favor of syntax.
Example:
Declaring a getter:
int foo {}
Just as a regular function declaration but without the
parentheses.
Declaring a setter:
void foo= (int value) {}
Append an equal sign to the function name.
How would you declare a template property? The getter would be
ambiguous with a regular function declaration, wouldn't it?
Re: D for scientific computing
On 01/26/2013 02:37 AM, Walter Bright wrote: If you're feeling ambitious, taking a closer look to see why would be most interesting. It's nice if DMD can produce faster code, but in the short term I'd rather see priority being given to making the frontend/druntime more easily portable to different backends. The speed issues of DMD have never bothered me, precisely because GDC and LDC exist -- and besides speed, there's also the issue of target architectures. The problem is rather having to wait for bugfixes and new features to propagate to the D compilers which already solved the speed and architecture issues.
Re: @property - take it behind the woodshed and shoot it?
On 2013-01-26 16:06, Nicolas Sicard wrote: How would you declare a template property? The getter would be ambiguous with a regular function declaration, wouldn't it? Right... didn't think of that. -- /Jacob Carlborg
Re: D for scientific computing
On Saturday, 26 January 2013 at 15:17:18 UTC, Joseph Rushton Wakeling wrote: ... ++ Once situation with front-end bugs and stability is settled, I see zero reasons to use dmd back-end and spending efforts on its optimization feels not pragmatical.
Re: On the subject of properties, and possibility of having them in the library
On Saturday, 26 January 2013 at 14:41:43 UTC, Simen Kjaeraas wrote: Now, the obstacle here is I can't refer to _n in those lambdas. Why not? I'm guessing the struct has no context member, and the lambdas don't because the class is not yet instantiated. Could this be fixed? I think so, and I think this is a feature with benefits beyond simple properties. Structs inside classes do not have access to outer scope (no outer property, no context pointer). Last time it was discussed month ago. There is probably a bugzilla issue for this but it seems it would not be fixed soon, let alone there were no consensus that it should work.
Re: D for scientific computing
On 01/26/2013 04:26 PM, mist wrote: Once situation with front-end bugs and stability is settled, I see zero reasons to use dmd back-end and spending efforts on its optimization feels not pragmatical. Actually, I feel somewhat the contrary. When the problem of frontend/runtime portability has been solved, then it makes plenty of sense to look at DMD speed and backend issues. Improving DMD is always a good thing -- it's just a question of priorities.
Re: D for scientific computing
Yes, of course, we all have our own preferences, that is fine :) I mean a bit different thing: front-end efforts affect all major compiler lovers, not only one group and thus are more important.
Re: @property - take it behind the woodshed and shoot it?
On Saturday, 26 January 2013 at 13:28:46 UTC, Jacob Carlborg wrote: On 2013-01-25 19:00, Rob T wrote: Why was a partial implementation of an experimental half-backed idea released into the wild? It seems just to be how things are done in the D community. Another recent example of this is the UDA that popped up and got implemented from nowhere. That is probably the #1 problem with D.
Re: Incorporating D
On Saturday, 26 January 2013 at 10:52:59 UTC, Rainer Schuetze
wrote:
On 26.01.2013 11:40, Johannes Pfau wrote:
Yes, I just wanted to point out a common source for such bugs,
it's not
the GC's fault. It's great that the documentation of toStringz
mentions
that issue. What I meant is most of the time we use
toStringz() like
this:
string str;
c_function(str.toStringz());
This is only valid if c_function doesn't store the pointer,
but newbies
might miss that and just copy this nice looking example code
for other
c functions. There's nothing we can do about that though,
interfacing
to C just is a little bit dangerous.
It is even dangerous if it is only used temporarily during that
function call, but copied elsewhere in the C heap and cleared
on the stack:
struct param_struct { const char* name; };
void c_function(const char*p)
{
param_struct* ps = new param_struct;
ps-name = p;
p = 0;
doSomething(ps);
delete ps;
}
Imagine a garbage collection while executing doSomething...
That isn't an issue as the pointer will e found at upper level in
the stack anyway.
Re: D for scientific computing
On 01/26/2013 04:43 PM, mist wrote: Yes, of course, we all have our own preferences, that is fine :) I mean a bit different thing: front-end efforts affect all major compiler lovers, not only one group and thus are more important. Yup, agree. :-)
Re: Incorporating D
On 26.01.2013 16:53, deadalnix wrote:
On Saturday, 26 January 2013 at 10:52:59 UTC, Rainer Schuetze wrote:
On 26.01.2013 11:40, Johannes Pfau wrote:
Yes, I just wanted to point out a common source for such bugs, it's not
the GC's fault. It's great that the documentation of toStringz mentions
that issue. What I meant is most of the time we use toStringz() like
this:
string str;
c_function(str.toStringz());
This is only valid if c_function doesn't store the pointer, but newbies
might miss that and just copy this nice looking example code for other
c functions. There's nothing we can do about that though, interfacing
to C just is a little bit dangerous.
It is even dangerous if it is only used temporarily during that
function call, but copied elsewhere in the C heap and cleared on the
stack:
struct param_struct { const char* name; };
void c_function(const char*p)
{
param_struct* ps = new param_struct;
ps-name = p;
p = 0;
doSomething(ps);
delete ps;
}
Imagine a garbage collection while executing doSomething...
That isn't an issue as the pointer will e found at upper level in the
stack anyway.
p = 0; clears the only existing reference on the stack.
Re: @property - take it behind the woodshed and shoot it?
On Saturday, 26 January 2013 at 13:28:46 UTC, Jacob Carlborg wrote: Another recent example of this is the UDA that popped up and got implemented from nowhere. That design is almost identical to a discussion we had a few months ago about it though; the timing was a surprise, but it wasn't bungled the way @property was.
Re: @property - take it behind the woodshed and shoot it?
On 1/26/13 8:21 AM, Jacob Carlborg wrote:
On 2013-01-25 22:20, Andrei Alexandrescu wrote:
That's right with the amendment that we're looking for a solution, not
pushing one. Even the title of the thread is a question.
Clearly properties are good to have. In an ideal world we wouldn't need
a keyword for them and we'd have some simple rules for determining
property status (especially when it comes to writes). If syntactic help
is necessary, so be it. We want to make the language better, not worse.
It's always possible to avoid keywords in favor of syntax. Example:
Declaring a getter:
int foo {}
Just as a regular function declaration but without the parentheses.
Declaring a setter:
void foo= (int value) {}
Append an equal sign to the function name.
This is interesting. I wonder how to make it work for UFCS functions
(which _do_ have one argument).
Andrei
Re: @property - take it behind the woodshed and shoot it?
On Saturday, 26 January 2013 at 16:29:16 UTC, Andrei Alexandrescu
wrote:
On 1/26/13 8:21 AM, Jacob Carlborg wrote:
On 2013-01-25 22:20, Andrei Alexandrescu wrote:
That's right with the amendment that we're looking for a
solution, not
pushing one. Even the title of the thread is a question.
Clearly properties are good to have. In an ideal world we
wouldn't need
a keyword for them and we'd have some simple rules for
determining
property status (especially when it comes to writes). If
syntactic help
is necessary, so be it. We want to make the language better,
not worse.
It's always possible to avoid keywords in favor of syntax.
Example:
Declaring a getter:
int foo {}
Just as a regular function declaration but without the
parentheses.
Declaring a setter:
void foo= (int value) {}
Append an equal sign to the function name.
This is interesting. I wonder how to make it work for UFCS
functions (which _do_ have one argument).
I have to say it will get my vote if a way if found to make this
UFCS compliant.
Its me
http://commons.wikimedia.org/wiki/File:US_Navy_070313-N-0120A-146_Staff_Sgt._Andrew_C._Edwards_polishes_the_American_flag_on_a_Marine_Corps_memorial_for_the_veterans_of_the_battle_for_Iwo_Jima_on_the_top_of_Mount_Suribachi.jpg
Re: auto ref - again
Yes. We are actively looking into a complete solution. Along the way we also very strongly want to define semantics of ref in such a way that makes unsafe escapes impossible. These two features are related. Andrei That's good to know. But can you estimate _when_ it will be implemented or with which version? That would be very informative.
Re: Its me
On 1/26/13 11:42 AM, Tyro[17] wrote: http://commons.wikimedia.org/wiki/File:US_Navy_070313-N-0120A-146_Staff_Sgt._Andrew_C._Edwards_polishes_the_American_flag_on_a_Marine_Corps_memorial_for_the_veterans_of_the_battle_for_Iwo_Jima_on_the_top_of_Mount_Suribachi.jpg Like. I'm not sure why but this makes the recent forum flamewars seem so petty. https://twitter.com/incomputable/status/295214888761044993 Andrei
Re: auto ref - again
On Saturday, 26 January 2013 at 16:27:04 UTC, Andrei Alexandrescu wrote: On 1/26/13 6:03 AM, Namespace wrote: In relation to this post: http://forum.dlang.org/thread/ssiulznvtkmfkimma...@forum.dlang.org?page=5#post-knnghuzbzqddaqcjtvch:40forum.dlang.org I hereby open up again the discussion about auto ref. There are only some questions: Will auto ref be implemented in the near future or not? Yes. We are actively looking into a complete solution. Along the way we also very strongly want to define semantics of ref in such a way that makes unsafe escapes impossible. These two features are related. Wouldn't it be nice if such thing would be settled BEFORE breaking quite a lot of code when changing this behavior in 2.061 ?
Re: @property - take it behind the woodshed and shoot it?
On 2013-01-26 17:29, Andrei Alexandrescu wrote: This is interesting. I wonder how to make it work for UFCS functions (which _do_ have one argument). There's two problems with the getter syntax. 1. How to distinguish a template property from a regular function 2. How to distinguish a property without an implementation from a variable declaration -- /Jacob Carlborg
Re: auto ref - again
On Saturday, 26 January 2013 at 17:02:40 UTC, deadalnix wrote: On Saturday, 26 January 2013 at 16:27:04 UTC, Andrei Alexandrescu wrote: On 1/26/13 6:03 AM, Namespace wrote: In relation to this post: http://forum.dlang.org/thread/ssiulznvtkmfkimma...@forum.dlang.org?page=5#post-knnghuzbzqddaqcjtvch:40forum.dlang.org I hereby open up again the discussion about auto ref. There are only some questions: Will auto ref be implemented in the near future or not? Yes. We are actively looking into a complete solution. Along the way we also very strongly want to define semantics of ref in such a way that makes unsafe escapes impossible. These two features are related. Wouldn't it be nice if such thing would be settled BEFORE breaking quite a lot of code when changing this behavior in 2.061 ? Absolute agreement. While it is true that structs are not lvalues, but to fix this known bug, without implement a solution for rvalue references was a really bad idea. This bug was so long tolerated because we hadn't a solution for rvalue references. So it would be good to know, why it was fixed this time, although we have still no rvalue refs.
Re: @property - take it behind the woodshed and shoot it?
On 2013-01-26 17:26, Adam D. Ruppe wrote: That design is almost identical to a discussion we had a few months ago about it though; the timing was a surprise, but it wasn't bungled the way @property was. Not the syntax. Walter added a two syntaxes one deprecated using brackets and the one we're using now with the at sign and parentheses. -- /Jacob Carlborg
Re: Make dur a property?
On Sat, 26 Jan 2013 12:33:11 +0100 Jacob Carlborg d...@me.com wrote: On 2013-01-25 20:27, Nick Sabalausky wrote: I agree in principle, but unfortunately return zis variable getters are often needed because no major language (that I know of) offers any other way to create data that's privately-writable and publicly-read-only - a very common need. Ie, that's the something that is wrong already: the lack of a simple built-in The public can only read this, but I can R/W it. to obviate an extremely common idiom. In Ruby one would do: class Foo attr_reader :foo end This would create a getter and an instance variable. Internally one can write directly do the instance variable, or create a setter: class Foo attr_reader :foo private def foo= (value) # code end end The equal sign indicates the method is a property. Not that attr_reader is not a language feature, it's implemented in the core library. There are also functions available for getter and both getter and setter. In D, I would like to see something like this: @property(get, set) int a; @property(get) int b; @property(set) int c; @property int d; // same as a This would create a getter and/or setter and an instance variable. One could also experiment with the protection attributes like this: public @property(get, protected set) int a; One way could affect the instance variable, the other way to affect the getter/setter implementation. Interesting. Although with that in mind it seems my earlier statement is not entirely true. There are languages that offer a publically read-only feature: C# and Haxe. I think it just didn't occur to me because they do it via shorthand versions of their property syntaxes.
Re: auto ref - again
On Saturday, January 26, 2013 17:51:23 Namespace wrote: That's good to know. But can you estimate _when_ it will be implemented or with which version? That would be very informative. Things generally just don't work that way around here. They get done when they get done. And often some of the more important stuff takes a while, because it takes a while to get the design sorted out and implemented (especially if Walter is the one to implement it). So, much as it might be nice to have a roadmap saying when something is expected to be done, that pretty much never happens. - Jonathan M Davis
Re: @property - take it behind the woodshed and shoot it?
On Saturday, 26 January 2013 at 13:21:37 UTC, Jacob Carlborg
wrote:
It's always possible to avoid keywords in favor of syntax.
Example:
Declaring a getter:
int foo {}
Just as a regular function declaration but without the
parentheses.
Declaring a setter:
void foo= (int value) {}
Append an equal sign to the function name.
This looks nice, but I favor for C# properties.
The root of the issue is that in C/C++/D there is tremendous
difference between object types and functions types (which are
incompatible) and property is like a bridge between them - I
think that is why the feature is demanded.
However in D a property is essentially a function. Few
characteristics that are intrinsic to data types are typeof(prop)
which is data type for properties and parenthesis-less access.
There is no property as a special entity per se.
In C# property and getter/setter are separated, so there is no
confusion between data and functions. In D it would look like
this:
class A
{
private int i;
@property int foo // may be without @property at all?
{
get { return i; }
set { i = @value; }
}
}
In this solution property is not defined by naming of two
separate functions and is independent of any function in general.
Re: On the subject of properties, and possibility of having them in the library
On 01/26/2013 03:41 PM, Simen Kjaeraas wrote:
While the storm raged, I decided to try implementing properties as
library types. I encountered a few obstacles, which I will outline here.
First, my intended syntax:
class A {
int _n;
mixin Property!(
() = _n,
value = _n = value
) n;
}
...
http://d.puremagic.com/issues/show_bug.cgi?id=7653
Re: @property - take it behind the woodshed and shoot it?
On Sat, 26 Jan 2013 11:10:20 -0800, Maxim Fomin ma...@maxim-fomin.ru
wrote:
On Saturday, 26 January 2013 at 13:21:37 UTC, Jacob Carlborg wrote:
It's always possible to avoid keywords in favor of syntax. Example:
Declaring a getter:
int foo {}
Just as a regular function declaration but without the parentheses.
Declaring a setter:
void foo= (int value) {}
Append an equal sign to the function name.
This looks nice, but I favor for C# properties.
The root of the issue is that in C/C++/D there is tremendous difference
between object types and functions types (which are incompatible) and
property is like a bridge between them - I think that is why the feature
is demanded.
However in D a property is essentially a function. Few characteristics
that are intrinsic to data types are typeof(prop) which is data type for
properties and parenthesis-less access. There is no property as a
special entity per se.
In C# property and getter/setter are separated, so there is no confusion
between data and functions. In D it would look like this:
class A
{
private int i;
@property int foo // may be without @property at all?
{
get { return i; }
set { i = @value; }
}
}
In this solution property is not defined by naming of two separate
functions and is independent of any function in general.
C# does not have a property keyword precisely because get/set are enough
for the compiler to determine whether or not it is a property.
So this is completely valid C#:
class A
{
private int i;
public int foo
{
get { return i; }
set { i = @value; }
}
}
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Re: auto ref - again
On Saturday, 26 January 2013 at 19:08:20 UTC, Jonathan M Davis wrote: On Saturday, January 26, 2013 17:51:23 Namespace wrote: That's good to know. But can you estimate _when_ it will be implemented or with which version? That would be very informative. Things generally just don't work that way around here. They get done when they get done. And often some of the more important stuff takes a while, because it takes a while to get the design sorted out and implemented (especially if Walter is the one to implement it). So, much as it might be nice to have a roadmap saying when something is expected to be done, that pretty much never happens. - Jonathan M Davis And why? For special cases like this it could be helpfull and it is IMO possible. You have the pull and know what's went wrong with it (it breaks unittests). So you could say, how long it takes, until it is ready to merge. Another proposal, that I've suggested in another thread, would be to merge some placeholder pull which fix the problem until the official solution is implemented. I thought about this pull: https://github.com/D-Programming-Language/dmd/pull/1428 It is ready for merging and usage. This pull adds functionality for non-template auto refs but it doesn't change the (template) auto ref functionality in general, as Kenjis pull does.
Re: Mac OS installer
I have been able to compile and run D programs for quite some time. I just thought I was using the 2.060 version of the compiler you gave me, until I checked what version I was actually using. My guess is that the 2.061 installer may have installed the new DMD, despite the error message.
Re: D for scientific computing
I use DMD and GDC. DMD for debug builds and (since it is the reference compiler) to ensure language conformance. GDC for performance tests and release. In other terms, I don't expect the W3 reference browser to be the fastest, but to set the required standard for HTML interpretation. If you asked me, I'd keep all smart compiler optimizations out of DMD for sake of stability, compilation speed and maintenance effort. Some of what GCC does is amazing, but probably requires heaps of difficult to read code. (I once saw it SSE optimize my code where I was using a 4-byte struct with 3 used bytes that I did computations on in a loop.) -- Marco
Re: Incorporating D
On Friday, 25 January 2013 at 20:47:15 UTC, q66 wrote: On Friday, 25 January 2013 at 20:45:22 UTC, Szymon wrote: Hi, I would really like to start using D in our small company as a C++ replacement. With that in mind I do have few questions: 1) Is D2 really ready for production code? I often hear ppl complaining about compiler bugs or regressions causing them to drop D for now. Is it true that D has GC problems? 1a) no 1b) yes AFAWK, at least one major videogames studio is writing its new title in D.
Re: Incorporating D
On 1/26/2013 8:17 AM, Rainer Schuetze wrote:
On 26.01.2013 16:53, deadalnix wrote:
On Saturday, 26 January 2013 at 10:52:59 UTC, Rainer Schuetze wrote:
On 26.01.2013 11:40, Johannes Pfau wrote:
Yes, I just wanted to point out a common source for such bugs, it's not
the GC's fault. It's great that the documentation of toStringz mentions
that issue. What I meant is most of the time we use toStringz() like
this:
string str;
c_function(str.toStringz());
This is only valid if c_function doesn't store the pointer, but newbies
might miss that and just copy this nice looking example code for other
c functions. There's nothing we can do about that though, interfacing
to C just is a little bit dangerous.
It is even dangerous if it is only used temporarily during that
function call, but copied elsewhere in the C heap and cleared on the
stack:
struct param_struct { const char* name; };
void c_function(const char*p)
{
param_struct* ps = new param_struct;
ps-name = p;
p = 0;
doSomething(ps);
delete ps;
}
Imagine a garbage collection while executing doSomething...
That isn't an issue as the pointer will e found at upper level in the
stack anyway.
p = 0; clears the only existing reference on the stack.
No, because ps is on the stack, and ps points to a copy of p. Hence, that code
snippet is GC safe.
Re: Its me
On 1/26/2013 8:42 AM, Tyro[17] wrote: http://commons.wikimedia.org/wiki/File:US_Navy_070313-N-0120A-146_Staff_Sgt._Andrew_C._Edwards_polishes_the_American_flag_on_a_Marine_Corps_memorial_for_the_veterans_of_the_battle_for_Iwo_Jima_on_the_top_of_Mount_Suribachi.jpg Andrew, we are so very much looking forward to finally meeting you at Dconf!
Re: dmd json file output
On 1/26/2013 2:25 AM, Rainer Schuetze wrote: I updated dmd from github and had a look at the current json output: it's horrible. Below is a random example of a simple function. Yeah, it's pretty bad.
Re: Make dur a property?
On 2013-01-26 19:55, Nick Sabalausky wrote: Interesting. Although with that in mind it seems my earlier statement is not entirely true. There are languages that offer a publically read-only feature: C# and Haxe. I think it just didn't occur to me because they do it via shorthand versions of their property syntaxes. Depending on how you look at it, D1 with const variables does as well and Java with final variables. -- /Jacob Carlborg
Re: Its me
On Saturday, 26 January 2013 at 16:42:13 UTC, Tyro[17] wrote: http://commons.wikimedia.org/wiki/File:US_Navy_070313-N-0120A-146_Staff_Sgt._Andrew_C._Edwards_polishes_the_American_flag_on_a_Marine_Corps_memorial_for_the_veterans_of_the_battle_for_Iwo_Jima_on_the_top_of_Mount_Suribachi.jpg Cheers!
Re: Incorporating D
On 26.01.2013 21:13, Walter Bright wrote:
On 1/26/2013 8:17 AM, Rainer Schuetze wrote:
On 26.01.2013 16:53, deadalnix wrote:
On Saturday, 26 January 2013 at 10:52:59 UTC, Rainer Schuetze wrote:
On 26.01.2013 11:40, Johannes Pfau wrote:
Yes, I just wanted to point out a common source for such bugs, it's
not
the GC's fault. It's great that the documentation of toStringz
mentions
that issue. What I meant is most of the time we use toStringz() like
this:
string str;
c_function(str.toStringz());
This is only valid if c_function doesn't store the pointer, but
newbies
might miss that and just copy this nice looking example code for other
c functions. There's nothing we can do about that though, interfacing
to C just is a little bit dangerous.
It is even dangerous if it is only used temporarily during that
function call, but copied elsewhere in the C heap and cleared on the
stack:
struct param_struct { const char* name; };
void c_function(const char*p)
{
param_struct* ps = new param_struct;
ps-name = p;
p = 0;
doSomething(ps);
delete ps;
}
Imagine a garbage collection while executing doSomething...
That isn't an issue as the pointer will e found at upper level in the
stack anyway.
p = 0; clears the only existing reference on the stack.
No, because ps is on the stack, and ps points to a copy of p. Hence,
that code snippet is GC safe.
Please note that c_function is C/C++ code. The struct is allocated on
the C heap, not in GC memory. p = 0 clears the only reference in GC
scanned memory to the char array allocated and returned by toStringz().
Re: Incorporating D
On 2013-01-26 20:55, SomeDude wrote: AFAWK, at least one major videogames studio is writing its new title in D. For real? You must be joking. :)
Re: Incorporating D
On 1/26/2013 12:44 PM, Rainer Schuetze wrote: Please note that c_function is C/C++ code. The struct is allocated on the C heap, not in GC memory. p = 0 clears the only reference in GC scanned memory to the char array allocated and returned by toStringz(). Oh, I see what you mean. You're right.
Re: Incorporating D
On Saturday, 26 January 2013 at 20:54:30 UTC, FG wrote: On 2013-01-26 20:55, SomeDude wrote: AFAWK, at least one major videogames studio is writing its new title in D. For real? You must be joking. :) Tsss, it is a secret ;)
Re: @property - take it behind the woodshed and shoot it?
On 01/26/13 20:10, Maxim Fomin wrote:
On Saturday, 26 January 2013 at 13:21:37 UTC, Jacob Carlborg wrote:
It's always possible to avoid keywords in favor of syntax. Example:
Declaring a getter:
int foo {}
Just as a regular function declaration but without the parentheses.
Declaring a setter:
void foo= (int value) {}
Append an equal sign to the function name.
This looks nice, but I favor for C# properties.
The root of the issue is that in C/C++/D there is tremendous difference
between object types and functions types (which are incompatible) and
property is like a bridge between them - I think that is why the feature is
demanded.
However in D a property is essentially a function. Few characteristics that
are intrinsic to data types are typeof(prop) which is data type for
properties and parenthesis-less access. There is no property as a special
entity per se.
In C# property and getter/setter are separated, so there is no confusion
between data and functions. In D it would look like this:
class A
{
private int i;
@property int foo // may be without @property at all?
{
get { return i; }
set { i = @value; }
}
}
In this solution property is not defined by naming of two separate functions
and is independent of any function in general.
Hmm, the current state of them being defined by two separate functions really
isn't ideal. But introducing new keywords or magic identifiers just for this
does not seem right.
class A
{
private int i;
int foo {
out { return i; }
in(int v) { i = v; }
}
}
or
class A
{
private int i;
@property foo {
int out { return i; }
in(int v) { i = v; }
}
}
artur
Re: Incorporating D
On Saturday, 26 January 2013 at 14:41:20 UTC, Andrei Alexandrescu wrote: Also, http://dlang.org/bugstats suggests (red line) a downward trend of bugs reported and unfixed. I also played a bit with the chart generator and plotted open vs. resolved bugs for the past 365 days: http://goo.gl/OX9bo. It seems we're consistently reducing net opened issues since November. Andrei For comparison, I wonder what the situation is for the various major implementations of C++11. Anyone know? --rt
Fixing module-scope private
There was discussion recently about unpleasant name conflict possible with private module symbols. I have just encountered a sarcastically false statement on dlang.org : Private module members are equivalent to static declarations in C programs. Made me sad and wondering: was there any DIP after that thread or it has ended, as it often happens, with a decision to plan carefully? In latter case I may try to write one.
Re: @property - take it behind the woodshed and shoot it?
On Saturday, 26 January 2013 at 21:48:54 UTC, Artur Skawina wrote:
[..]
Hmm, the current state of them being defined by two separate
functions really
isn't ideal. But introducing new keywords or magic identifiers
just for this
does not seem right.
class A
{
private int i;
int foo {
out { return i; }
in(int v) { i = v; }
}
}
or
class A
{
private int i;
@property foo {
int out { return i; }
in(int v) { i = v; }
}
}
artur
In a more pefect world, we'd redefine what a variable and
function is, merging the two together as one, let the compiler
optimize things appropriately, and make the language issues far
more consistent and simple.
For example, typeof(x) is way too simplistic to be of use when
you have objects that have more than on type. For example, a
property has a setter, getter, and storage type, so what should
typeof(prop) return? It can only tell you one thing out of at
least 3 things, so it's insufficient.
Great for C, useless for D.
We're basically finding ourselves in the same position C++ has
found itself in, where the old concepts are no longer suitable
for a modern language, but there's no practical way to resolve
the situation without redesigning the whole language into a new
one. D tried to make a better C++, and it has done a good job of
that up to a point, but since it has made use of many of the old
paradigms as its base, it can only do so much.
One solution is to not bother trying to add on any extra
complexity that does not fit in.
--rt
Re: Fixing module-scope private
On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote: Made me sad and wondering: was there any DIP after that thread or it has ended, as it often happens, with a decision to plan carefully? I *think* Walter is still against changing it, on the grounds that it would make module-level private different from any other type of private.
Re: On the subject of properties, and possibility of having them in the library
On 2013-23-26 20:01, Timon Gehr timon.g...@gmx.ch wrote:
On 01/26/2013 03:41 PM, Simen Kjaeraas wrote:
While the storm raged, I decided to try implementing properties as
library types. I encountered a few obstacles, which I will outline here.
First, my intended syntax:
class A {
int _n;
mixin Property!(
() = _n,
value = _n = value
) n;
}
...
http://d.puremagic.com/issues/show_bug.cgi?id=7653
And how might that work?
--
Simen
Re: Fixing module-scope private
On Saturday, 26 January 2013 at 23:13:02 UTC, Peter Alexander wrote: I *think* Walter is still against changing it, on the grounds that it would make module-level private different from any other type of private. Well, I thought it was an agreement that we exactly lack currently way to do C global static or C++ unnamed namespace behavior. No opinion currently if this should be private or anything but statement from dlang.org I have cited is terribly wrong currently and something needs to be done about it.
Re: auto ref - again
On Saturday, January 26, 2013 20:25:15 Namespace wrote: On Saturday, 26 January 2013 at 19:08:20 UTC, Jonathan M Davis wrote: On Saturday, January 26, 2013 17:51:23 Namespace wrote: That's good to know. But can you estimate _when_ it will be implemented or with which version? That would be very informative. Things generally just don't work that way around here. They get done when they get done. And often some of the more important stuff takes a while, because it takes a while to get the design sorted out and implemented (especially if Walter is the one to implement it). So, much as it might be nice to have a roadmap saying when something is expected to be done, that pretty much never happens. - Jonathan M Davis And why? For special cases like this it could be helpfull and it is IMO possible. You have the pull and know what's went wrong with it (it breaks unittests). So you could say, how long it takes, until it is ready to merge. Another proposal, that I've suggested in another thread, would be to merge some placeholder pull which fix the problem until the official solution is implemented. I thought about this pull: https://github.com/D-Programming-Language/dmd/pull/1428 It is ready for merging and usage. This pull adds functionality for non-template auto refs but it doesn't change the (template) auto ref functionality in general, as Kenjis pull does. If we add a feature as a temporary measure and then remove it later, we're likely to end up breaking code when it's removed. It's not clear what the ultimate solution is going to be, particularly since Andrei is looking to fix refs in general (and based on previous discussions on this, I believe that Walter is looking to do the same), the solution could be more complicated. I don't know what they're going to do with it. But I'd be very surprised if anything were merged in to solve the problem before they've decided what they want to do. You seem to be in a big hurry to have this problem solved, but very little moves at that kind of pace around here, even if it's very important. If it were simply a bug fix, then someone (including you) could hop in, sort it out, and submit a fix, and it might get merged in fairly quickly (though the rate at which even straightforward pull requests gets merged in varies considerably). But this isn't just a bug fix. It affects the fundamental design of a portion of the language, which means that a design needs to be presented that satisfies both Walter and Andrei. Changes like that just don't happen quickly. And Andrei and Walter have some very definitive ideas about what they want to be able to guarantee with ref and @safe, and doing that isn't easy. I don't expect that any solution to this will be merged in until they've agreed upon a solution. And I have no idea how long that will take. It sounds like Andrei is treating it as a relatively high priority for himself to sort out the problem, but he's a very busy fellow, and pretty much anything that requires a lot of work on his part tends to take a while as a result. So, while I can understand your frustration (and on some level share it), on an issue like this, you're just going to have to be patient. Making a big deal about it may get it to happen faster by bringing more attention to it, but it's still not going to be as simple as just merging a pull request, not with an issue like this. - Jonathan M Davis
Re: @property - take it behind the woodshed and shoot it?
We can almost implement properties as a regular struct
struct prop
{
int _val;
ref prop opAssign( int a_val )
{
writeln(assignment = , a_val );
_val = a_val;
return this;
}
int opCall()
{
writeln(opcall = , _val );
return _val;
}
// other op overloads, like ++, --, etc
}
If we change a few things it may work. Instead of struct it could
be named prop
eg
prop P
{
...
}
opCall needs to be changed so there's no need to specify the ().
No dounbt other changes will be needed too to make it more
convenient to use and less error prone.
The advantage is that with a property as a struct
implementation, you can wrap up a lot more than just a setter and
getter around only one variable, eg internally there could be
several vars or even none at all depending on the needs.
--rt
Re: auto ref - again
If we add a feature as a temporary measure and then remove it later, we're likely to end up breaking code when it's removed. No, as far as I can see this don't happend. auto ref works currently very well for template functions and the pull I suggest adds the same functionality for normal functions. So if one day an official solution is there, nothing will be broken. The solutions code has (maybe) another implementation but it don't touch auto ref functionality in general. You seem to be in a big hurry to have this problem solved, but very little moves at that kind of pace around here, even if it's very important. Yes, in my opinion this feature is a very important and basic thing that every language should have. So, while I can understand your frustration (and on some level share it), on an issue like this, you're just going to have to be patient. Making a big deal about it may get it to happen faster by bringing more attention to it, but it's still not going to be as simple as just merging a pull request, not with an issue like this. - Jonathan M Davis Good to hear that I'm not alone with this.
Re: @property - take it behind the woodshed and shoot it?
On Sat, Jan 26, 2013 at 2:24 PM, Rob T al...@ucora.com wrote: We're basically finding ourselves in the same position C++ has found itself in, where the old concepts are no longer suitable for a modern language, but there's no practical way to resolve the situation without redesigning the whole language into a new one. D tried to make a better C++, and it has done a good job of that up to a point, but since it has made use of many of the old paradigms as its base, it can only do so much. That is what I have been noticing as well, unfortunately. As a long time lurker, I like many of the concepts that D introduces, but the many little quirks here and there add up and probably make adoption by a large community much less likely. It would be great if we had more programming languages competing to change the systems programming landscape. The popular systems languages we have been stuck with (namely C and C++) are a mess, and the replacements I see announced every once in a while never seem to become bigger than side projects. Currently, the only other potential option I see is Rust. Why not take it all the way? Start with a proper release plan, be willing to break backward compatibility (maybe even by changing the name of the language -- perception matters), take into account all what was learned from the past 10+ years of D's history, potentially try to get corporate backing, and maybe we will have something that is practically viable to push aside C and C++. Then again, maybe I dream too much... -- Ziad
Re: @property - take it behind the woodshed and shoot it?
On Sun, Jan 27, 2013 at 01:15:29AM +0100, Rob T wrote:
We can almost implement properties as a regular struct
[...]
You do it like this:
import std.stdio;
struct IntProp {
int __impl;
@property /* -- ah, the irony! */ int value() {
return __impl + 123;
}
alias value this; // watch this magic
void opAssign(int val) {
__impl = val - 123;
}
}
struct S {
IntProp prop;
}
void main() {
S s;
writeln(s.prop);
s.prop = 321;
writeln(s.prop);
}
T
--
Gone Chopin. Bach in a minuet.
Re: auto ref - again
On Sunday, January 27, 2013 01:32:07 Namespace wrote: If we add a feature as a temporary measure and then remove it later, we're likely to end up breaking code when it's removed. No, as far as I can see this don't happend. auto ref works currently very well for template functions and the pull I suggest adds the same functionality for normal functions. So if one day an official solution is there, nothing will be broken. The solutions code has (maybe) another implementation but it don't touch auto ref functionality in general. But it may not even end up being the case that using auto ref on non-templated functions is the solution. It may end up being something else entirely. Ignoring @safety issues, it seems to me like it would be the most straightforward solution, but there are @safety issues with ref in general that need to be addressed, and Andrei intends to address them as part of whatever happens with auto ref. That mean that auto ref gets used for non- templated functions, or it could mean something very different. I don't know what exactly the solution that Andrei is working on could entail. For all I know, it'll involve letting ref in general accept rvalues (much as I tihnk that that's a horrible idea, it _has_ been suggested before). So, without a clear idea of what we're going to want to do, merging in the pull request which makes auto ref work for non-templated functions is a bad idea. It could ultimately end up being fine, or it could end up breaking more code when the real solution gets implemented. - Jonathan M Davis
Re: @property - take it behind the woodshed and shoot it?
On 1/26/2013 5:21 AM, Jacob Carlborg wrote:
On 2013-01-25 22:20, Andrei Alexandrescu wrote:
That's right with the amendment that we're looking for a solution, not
pushing one. Even the title of the thread is a question.
Clearly properties are good to have. In an ideal world we wouldn't need
a keyword for them and we'd have some simple rules for determining
property status (especially when it comes to writes). If syntactic help
is necessary, so be it. We want to make the language better, not worse.
It's always possible to avoid keywords in favor of syntax. Example:
Declaring a getter:
int foo {}
Just as a regular function declaration but without the parentheses.
Problems if you want to declare the getter but not provide an implementation.
Declaring a setter:
void foo= (int value) {}
Append an equal sign to the function name.
It is rather similar to a variable declaration with initializer:
T foo = expression;
Re: auto ref - again
On Sunday, 27 January 2013 at 01:23:18 UTC, Jonathan M Davis wrote: But it may not even end up being the case that using auto ref on non-templated functions is the solution. It may end up being something else entirely. Ignoring @safety issues, it seems to me like it would be the most straightforward solution, but there are @safety issues with ref in general that need to be addressed, and Andrei intends to address them as part of whatever happens with auto ref. That mean that auto ref gets used for non- templated functions, or it could mean something very different. I don't know what exactly the solution that Andrei is working on could entail. For all I know, it'll involve letting ref in general accept rvalues (much as I tihnk that that's a horrible idea, it _has_ been suggested before). So, without a clear idea of what we're going to want to do, merging in the pull request which makes auto ref work for non-templated functions is a bad idea. It could ultimately end up being fine, or it could end up breaking more code when the real solution gets implemented. Having ref accept rValues seems like a bad idea. If the source is const/immutable then it might be allowed, but more likely temporaries will be made for convertion from rValues to lValues, then passing off the temporaries. The temporaries to work right likely need to be at the top-most scope of whatever function you happen to be in; Beyond that I'm not sure how else the auto ref could be implemented safely.
Re: @property - take it behind the woodshed and shoot it?
On Sunday, 27 January 2013 at 01:11:05 UTC, H. S. Teoh wrote:
On Sun, Jan 27, 2013 at 01:15:29AM +0100, Rob T wrote:
We can almost implement properties as a regular struct
[...]
You do it like this:
import std.stdio;
struct IntProp {
int __impl;
@property /* -- ah, the irony! */ int value() {
return __impl + 123;
}
alias value this; // watch this magic
void opAssign(int val) {
__impl = val - 123;
}
}
struct S {
IntProp prop;
}
void main() {
S s;
writeln(s.prop);
s.prop = 321;
writeln(s.prop);
}
T
Ah cool! You don't really need @property however if we adopt the
optional () unless that's to be enforced.
The really nice thing about this, is we can return the struct as
a ref, and it still works, and also take the address of the
struct and it continues to work.
Even better I can add more member functions to it and expand on
what it can do. The property as a function approach is far more
limiting and has issues, such as ref returns and taking the
address.
Anyone know what's missing or what won't work with this approach?
--rt
Re: @property - take it behind the woodshed and shoot it?
It would be cool if we could declare variables with anonymous
types;
struct { opAssign() {} } foo;
