Re: Getters/setters generator
On Tuesday, 17 January 2017 at 07:06:05 UTC, Stefan Koch wrote:
On Tuesday, 17 January 2017 at 06:26:35 UTC, Eugene Wissner
wrote:
On Friday, 9 December 2016 at 18:53:55 UTC, Andrei
Alexandrescu wrote:
Love it, and was toying with similar ideas too. One good
extension is to add a predicate to the setter, which guards
the assignment. -- Andrei
What kind of predicate do you mean? Can you give an example
please?
setValue(uint _under24)
{
assert(_under24 < 24);
under24 = _under24;
}
Ah, well thanks. I don't think it makes much sense since it would
be easier to write a complete setter if the user needs extra
checks. Accessors are there only for the generation of the
standard methods, that just get or set some object property.
Re: Getters/setters generator
On Tuesday, 17 January 2017 at 06:26:35 UTC, Eugene Wissner wrote:
On Friday, 9 December 2016 at 18:53:55 UTC, Andrei Alexandrescu
wrote:
Love it, and was toying with similar ideas too. One good
extension is to add a predicate to the setter, which guards
the assignment. -- Andrei
What kind of predicate do you mean? Can you give an example
please?
setValue(uint _under24)
{
assert(_under24 < 24);
under24 = _under24;
}
Re: Getters/setters generator
On Friday, 9 December 2016 at 18:53:55 UTC, Andrei Alexandrescu wrote: Love it, and was toying with similar ideas too. One good extension is to add a predicate to the setter, which guards the assignment. -- Andrei What kind of predicate do you mean? Can you give an example please?
Re: Getters/setters generator
On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote:
Hello,
we've just open sourced a small module ("accessors") that helps
to generate getters and setters automatically:
https://github.com/funkwerk/accessors
http://code.dlang.org/packages/accessors
It takes advantage of the UDAs and mixins. A simple example
would be:
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
mixin(GenerateFieldAccessors);
}
It would generate 2 methods "num": one to set num_ and one to
get its value. Of cause you can generate only @Read without
@Write and vice versa. There are some more features, you can
find the full documentation in the README.
"GenerateFieldAccessors" mixin should be added into each
class/struct that wants to use auto generated accessors.
We just released the next version of the accessors: v1.1.0
- One problem with inheritance was fixed.
- And the generated accessors are always properties know.
Re: Android LDC in a Container
Le 15/01/2017 à 18:40, Andre Pany a écrit : Hi, on Dockerhub I published a repository which makes it really easy to develop Android applications using LDC and Joakims work. The repository contains Android 1.1.0 beta from https://github.com/joakim-noah/android/releases and also the NDK from google. By using this command, you will have a shell containing all you need to compile the source files: docker run --rm -it -v c:/D/projects:/projects andre2007/ldc-android sh This command will also mount C:\D\projects from your host OS to the container path /projects. On linux / mac you will have to adapt the mount source path. You need the Google Android SDK on your host system installed to build the APK and test the application. More information on building the demo applications you can find here: https://wiki.dlang.org/Build_LDC_for_Android A Wiki update will follow with detailed information. Kind regards André It's really nice to see the Android support progress like that. I hope to see the integration of this with dub, to be able to use Visual to target Android with ldc. Thank you.
Re: Pry v0.3.1 is out!
On 1/16/17 1:29 AM, Bastiaan Veelo wrote: On Sunday, 15 January 2017 at 01:26:07 UTC, Dmitry Olshansky wrote: Pry is a new pragmatic parser combinators library. https://github.com/DmitryOlshansky/pry Interesting. How about left-recursion? (I added support for left-recursive grammars to Pegged.) I think left-recursion is better handled at the grammar level. What I currently have is parser combinators level where adding this transformation is awkward and too much magic IMO. However I plan to add a grammar on top of combinators, and yes handling left-recursive grammars is going to be an interesting challenge. --- Dmitry Olshansky
Re: Vision document for H1 2017
On Friday, 13 January 2017 at 04:02:38 UTC, Jonathan M Davis wrote: On Thursday, January 12, 2017 21:57:37 Andrew Browne via Digitalmars-d- announce wrote: On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: > We release a brief Vision document summarizing the main > goals we plan to pursue in the coming six months. This half > we are focusing on three things: safety, lifetime > management, and static introspection. > > https://wiki.dlang.org/Vision/2017H1 > > > Andrei Is there a design document for how D will achieve safety with nogc? How does D plan to prevent leaks, use-after-free, double-free bugs when not using the GC? Part of the reason that we have the GC in D is because of the safety guarantees that you can have with a GC that you can't have with mechanisms like malloc and free. Some amount of @nogc code can be @safe, but some of it will never be able to be @safe. e.g. the very nature of malloc and free makes @safe impossible in the general case. This is why I ask. Because the vision document says "2. @nogc: Use of D without a garbage collector, most likely by using reference counting and related methods Unique/Weak references) for reclamation of resources. This task is made challenging by the safety requirement." It sounds like @safe @nogc code is the goal. I know it is challenging, I'd like to know if there is a plan/design for how to achieve this. It's trivial for a piece of code to free something that's currently in use by other code. If they're constrained within a ref-counting system, then @safety becomes more possible, but even then, when you have to start worrying about stuff like weak references in order to get around circular reference problems, it gets dicey if not impossible to make it fully @safe. Yep, circular references are a difficulty of ref-counting. Is there a plan/design for how to handle this? It might be possible to guarantee safety if you have a whole bunch of extra constraints like Rust does with its borrowing stuff, but we're not going to add something like that to D, because it's too complicated on top of everything else that we already have. So that level of safety is just not a goal of D? If I want memory safe code without a GC, should I just use Rust? I fully expect that certain idioms will be in place to help maintain @safety in @nogc code, but to some extent, by abandoning the GC, you're abandoning @safety - or at least you're making a lot more of your code need to be @trusted, and you can rely less on the compiler to guarantee @safety for you. Taking the freeing of memory out of the hands of the programmer like happens with the GC is _huge_ in guaranteeing the memory safety of code. Will @nogc also have first class support in the language? And what do you mean my first class support? Some features require the GC, and I wouldn't expect it to ever be otherwise. Giving up the GC means giving up on certain features. We don't want that list to be longer that it needs to be, but some stuff fundamentally needs the GC to do what it does. That is what I meant. The next questions are examples of what I meant. Afaik the GC is currently needed for language features like array concatenation. Will features like array concatentation still work with @nogc? I don't see how it possibly could given how dynamic arrays work in D. It would have to have some sort of reference counting mechanism, which would likely be a nightmare with slicing and certainly does not at all play well with how low level D arrays are. We may very well get some sort of ref-counted array type that has concatenation, but it would be a library construct rather than in the language, because it doesn't need to be in the language, and the built-in arrays would not be affected by it. GC allocations have a keyword 'new' (afaik 'new' currently never means anything other than GC allocation). Will we be able to do @nogc allocations by the 'new' keyword? I very much doubt it. Constructing objects into memory is done via emplace, which is a library construct, and there's really no need for it to be in the language. As it is, if we were doing things from scratch, new probably wouldn't even be a keyword. It would likely be a library construct in druntime, because D is powerful enough that new doesn't need to be in the language to do what it does. And in general, at this point, Walter and Andrei don't want to put stuff in the language unless it actually needs to be there. If it can be done with a library, it will be done with a library. The only reason that they decided that we needed some sort of ref-counting mechanism in the language is because they decided that it wasn't actually possible to make it fully @safe without it being part of the language. And even then, I'm not sure that the intention is that the ref-counting mechanism use anything other than the GC. It's not yet clear what it's going to
Re: SmartRef： The Smart Pointer In D
On Monday, 16 January 2017 at 01:54:35 UTC, Dsby wrote:
On Sunday, 15 January 2017 at 17:24:25 UTC, biozic wrote:
On Sunday, 15 January 2017 at 15:56:30 UTC, Dsby wrote:
and : In
https://github.com/dlang/phobos/blob/master/std/typecons.d#L147
~this()
{
debug(Unique) writeln("Unique destructor of ", (_p is
null)? null: _p);
if (_p !is null) destroy(_p);
_p = null;
}
if the 'T' is a struct, it will not exec the Destory
function. Is it a bug?
What do you mean? This works for me:
---
import std.stdio, std.typecons;
struct Foo {
~this() {
writeln("I'm destroyed");
}
}
void main() {
Unique!Foo foo = new Foo;
} // Prints "I'm destroyed"
---
the "writeln("I'm destroyed");" not run the ~this in the Unique
destroy function.
it run in the app exit , THe GC distroy all memony.
it example can show :
import std.stdio;
import std.typecons;
struct Foo {
~this() {
writeln("I'm destroyed");
}
}
void fun(){
Unique!Foo foo = new Foo;
writeln("exit the fun.");
}
void main() {
fun();
writeln("exit the Main.");
}
It is the printf:
~/tmp rdmd ./type.d
2017年01月16日 星期一 09时50分00秒
exit the fun.
exit the Main.
I'm destroyed
~/tmp
if you use the struct in Unique, the struct's Destory function
is not run in the Unique destroy, it is also run in the GC
collet.
I think it is not the Unique should be.
Right, good point. This behaviour is indeed caused by destroy()
and is not specific to Unique. But it the case of Unique, relying
on this (undefined?) behaviour of destroy is a bug (a regression).
