Re: Digital Audio Workstation in D
On Monday, 15 February 2016 at 02:31:21 UTC, Rikki Cattermole wrote: Are you interested in taking ownership of the more basic primitives? Ownership as in "Only I can work on this."? If so, no. I have little to no experience with audio I/O, X11 or DirectX/Windows API. I'm just a somewhat quick learner, especially when learning something can help achieve my goals (in this case, being able to customize the software I use to create music). Being "fully D" is not a priority to me, initially depending on SDL and later switching the low-level libraries to pure D implementations is totally fine. Once I've learned more about the insides of audio software and the native APIs on multiple platforms, I might be able to contribute to said audio primitives. Until then, Ketmar seems a more suited candidate (already has a multi-channel sound engine, Follin[0] in the works (only on ALSA, though) ). P.S. Thanks for your work on windowing and image handling, will be very useful once an actual GUI for the DAW is needed. [0] http://repo.or.cz/iv.d.git/tree/refs/heads/master:/follin
Re: Weird issue with std.range.iota.length
On Sunday, 14 February 2016 at 13:16:58 UTC, Jonathan M Davis wrote: On Sunday, 14 February 2016 at 10:59:41 UTC, w0rp wrote: Maybe I'm missing something, but can't the length just be size_t? I doubt there is much you could do with code which generates finite sequences larger than the addressable memory space, aside from very abstract and inefficient mathematical calculations which skip over elements. iota would probably work better with size_t in most cases, and if you really well and truly need something which generates finite sequences of integers larger than the addressable memory space, you can always just write your own version. Yeah. It would be easy enough to just make iota size_t and then have it check the actual length of the range when it's called to make sure that it's not larger than will fit in size_t (and presumably throw a RangeError if the number of elements is too large). Anyone who really wants to have a range with more than size_t.max elements can write their own thing. It's not like it's going to work nicely with other ranges anyway - at least not as long as it defines length. - Jonathan M Davis +1
Re: Digital Audio Workstation in D
On Monday, 15 February 2016 at 07:55:22 UTC, Tanel Tagaväli wrote: Once I've learned more about the insides of audio software and the native APIs on multiple platforms, I might be able to contribute to said audio primitives. I think you should forget about creating abstractions. Use the low level audio API for the platform directly. But you haven't really said what features you want. You basically need to read up on signal processing... A good DSP C-library is the main bottleneck for such a project. I haven't been able to find a BSD style licensed high quality polyphase resampling library. Which is what you need if you want to efficiently change pitch on the fly. If someone knows of one, please let me know :-).
Re: Digital Audio Workstation in D
On 15/02/16 8:55 PM, Tanel Tagaväli wrote: On Monday, 15 February 2016 at 02:31:21 UTC, Rikki Cattermole wrote: Are you interested in taking ownership of the more basic primitives? Ownership as in "Only I can work on this."? If so, no. Onwership as in somebody needs to spear head the work ;) I have little to no experience with audio I/O, X11 or DirectX/Windows API. I'm just a somewhat quick learner, especially when learning something can help achieve my goals (in this case, being able to customize the software I use to create music). The major reason why I'm not working on this myself is because I already have enough on my plate and I have no clue about audio code. Most of what you need is fairly simple, its just a lot to take in. Being "fully D" is not a priority to me, initially depending on SDL and later switching the low-level libraries to pure D implementations is totally fine. Once I've learned more about the insides of audio software and the native APIs on multiple platforms, I might be able to contribute to said audio primitives. Until then, Ketmar seems a more suited candidate (already has a multi-channel sound engine, Follin[0] in the works (only on ALSA, though) ). Ketmar definitely would not want to work on it. The only person I know who could is p0nce and he's pretty busy as it stands with his own audio work. P.S. Thanks for your work on windowing and image handling, will be very useful once an actual GUI for the DAW is needed. [0] http://repo.or.cz/iv.d.git/tree/refs/heads/master:/follin
Re: Babylon JS-like game engine or complete port
On Saturday, 13 February 2016 at 09:07:03 UTC, karabuta wrote: I would prefer to use blender and import assets. How about that? I made a program that does exactly that[0] using GFM, SDL and assimp. [0] https://github.com/clinei/3ddemo
Speed kills
Every time there is a D thread on reddit it feels like the new user is expecting mind-blowing speed from D. https://www.reddit.com/r/programming/comments/45v03g/porterstemmerd_an_implementation_of_the_porter/ This is the most recent one where John Colvin provided some pointers to speed it up significantly. Walter has done some good work taking the low-hanging fruit to speed up DMD code and there is a lot of effort going on with reference counting machinery but I wondered if some of the common errors people make that slow down D code can be addressed? Literals used to be a hidden speed bump but I think that was improved, now the append operator is one of the most common culprits, can this not be enhanced behind the scenes to work more like append? Do others notice common pitfalls between the article code and what the D community then suggests where we can bridge the gap so naive users get faster code?
Encode string as json string
Other than generating normal JSON content (stringify), JSON
string is used for Javascript string expressions as well.
To create a properly encoded Javascript string, the shortest way
is
JSONValue("this'\\is//the\"text").toString();
Yes, it works, but it is uncomfortable to write the code as
above. Two issues:
1. It creates a struct, and there are extra processing in the
background (check the source code for this.)
2. It is really long.
std.json already has a string encoding function in it, but it is
not exposed outside.
https://github.com/D-Programming-Language/phobos/blob/master/std/json.d#L1002
It would be quite useful to expose this function for ease of use.
Any thoughts?
Re: Speed kills
On Monday, 15 February 2016 at 13:51:38 UTC, ixid wrote: This is the most recent one where John Colvin provided some pointers to speed it up significantly. Walter has done some good work taking the low-hanging fruit to speed up DMD code and there is a lot of effort going on with reference counting machinery but I wondered if some of the common errors people make that slow down D code can be addressed? Something that annoyed me a bit is floating-point comparisons, DMD does not seem to be able to handle them from SSE registers, it will convert to FPU and do the comparison there IIRC.
Re: Babylon JS-like game engine or complete port
On Monday, 15 February 2016 at 11:07:31 UTC, Tanel Tagaväli wrote: On Saturday, 13 February 2016 at 09:07:03 UTC, karabuta wrote: I would prefer to use blender and import assets. How about that? I made a program that does exactly that[0] using GFM, SDL and assimp. [0] https://github.com/clinei/3ddemo Cool, it runs just well here.
Re: Digital Audio Workstation in D
On Monday, 15 February 2016 at 10:52:17 UTC, Ola Fosheim Grøstad wrote: I haven't been able to find a BSD style licensed high quality polyphase resampling library. Which is what you need if you want to efficiently change pitch on the fly. This library exist, the author Aleksey Vaneev is basically a DSP greek semi-god. https://github.com/avaneev/r8brain-free-src By the same author: https://github.com/avaneev/avir
Re: Digital Audio Workstation in D
On Monday, 15 February 2016 at 11:03:09 UTC, Rikki Cattermole wrote: Ketmar definitely would not want to work on it. The only person I know who could is p0nce and he's pretty busy as it stands with his own audio work. Indeed, but as part of speed/regression testing there is a crappy VST host in dplug:host sub-package that can be used to process data with an audio plugin. Which allows you to reuse the wealth of plugins out there.
Re: Encode string as json string
On Monday, 15 February 2016 at 14:09:04 UTC, tcak wrote:
Other than generating normal JSON content (stringify), JSON
string is used for Javascript string expressions as well.
To create a properly encoded Javascript string, the shortest
way is
JSONValue("this'\\is//the\"text").toString();
Yes, it works, but it is uncomfortable to write the code as
above. Two issues:
1. It creates a struct, and there are extra processing in the
background (check the source code for this.)
2. It is really long.
std.json already has a string encoding function in it, but it
is not exposed outside.
https://github.com/D-Programming-Language/phobos/blob/master/std/json.d#L1002
It would be quite useful to expose this function for ease of
use. Any thoughts?
I've been using http://code.dlang.org/packages/std_data_json
instead, and it's in the running to be a replacement for std.json
(though I don't know quite what the status of all that it is; it
was reviewed but still had work it needed IIRC). It's worked well
enough for me and might do better for you than std.json. I don't
know though. I pretty much only use JSON when I have to.
- Jonathan M Davis
Re: Speed kills
On Monday, 15 February 2016 at 14:16:02 UTC, Guillaume Piolat wrote: Something that annoyed me a bit is floating-point comparisons, DMD does not seem to be able to handle them from SSE registers, it will convert to FPU and do the comparison there IIRC. I feel like this point comes up often, and that a lot of people have argued x87 FP should just not happen anymore. -Wyatt
Re: Speed kills
On Monday, 15 February 2016 at 13:51:38 UTC, ixid wrote: Every time there is a D thread on reddit it feels like the new user is expecting mind-blowing speed from D. [...] if you want better codegen, don't use dmd. use ldc, it's usualy only a version-ish behind dmd.
Re: Speed kills
On Monday, 15 February 2016 at 14:16:02 UTC, Guillaume Piolat
wrote:
On Monday, 15 February 2016 at 13:51:38 UTC, ixid wrote:
This is the most recent one where John Colvin provided some
pointers to speed it up significantly. Walter has done some
good work taking the low-hanging fruit to speed up DMD code
and there is a lot of effort going on with reference counting
machinery but I wondered if some of the common errors people
make that slow down D code can be addressed?
Something that annoyed me a bit is floating-point comparisons,
DMD does not seem to be able to handle them from SSE registers,
it will convert to FPU and do the comparison there IIRC.
Same for std.math.lround
they use the FP way while for float and double it's only one sse
instruction. Typically with 6 functions similar to this one:
int round(float value)
{
asm
{
naked;
cvtss2si EAX, XMM0;
ret;
}
}
we could get ceil/trunc/round/floor, also almost as easily fmod,
hypoth.
classic but I dont get why thery're not in std.math.
Goddamnit, we're in 2016.
Head Const
rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const will do for us: 1. make it easy to interface to C++ code that uses const, as currently it is not very practical to do so, you have to resort to pragma(mangle) 2. supports single assignment style of programming, even if the data is otherwise mutable The downside is, of course, language complexity.
Re: Head Const
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const will do for us: 1. make it easy to interface to C++ code that uses const, as currently it is not very practical to do so, you have to resort to pragma(mangle) 2. supports single assignment style of programming, even if the data is otherwise mutable The downside is, of course, language complexity. I'll leave to others to discuss whether a language solution is worth it, but I just wanted to point out there are two library solutions in this area: HeadConst [1] - PR pending, and Rebindable (tail const) [2] - already part of Phobos. Maybe if the language could express head const, it also makes sense to have tail const. [1]: https://github.com/D-Programming-Language/phobos/pull/3862 [2]: http://dlang.org/phobos-prerelease/std_typecons.html#.Rebindable
Re: Speed kills
On Monday, 15 February 2016 at 22:29:00 UTC, Basile B. wrote: we could get ceil/trunc/round/floor, also almost as easily fmod, hypoth. classic but I dont get why thery're not in std.math. Seems like you know a lot about the subject, and I know you contributed to phobos before, so how about making a PR for this :)
Re: Speed kills
On Monday, 15 February 2016 at 22:29:00 UTC, Basile B. wrote:
Same for std.math.lround
they use the FP way while for float and double it's only one
sse instruction. Typically with 6 functions similar to this one:
int round(float value)
{
asm
{
naked;
cvtss2si EAX, XMM0;
ret;
}
}
we could get ceil/trunc/round/floor, also almost as easily
fmod, hypoth.
classic but I dont get why thery're not in std.math.
Goddamnit, we're in 2016.
lround and friends have been a big performance problem at times.
Everytime you can use cast(int) instead, it's way faster.
Re: Head Const
On 2/15/2016 3:11 PM, ZombineDev wrote: I'll leave to others to discuss whether a language solution is worth it, but I just wanted to point out there are two library solutions in this area: HeadConst [1] - PR pending, and Rebindable (tail const) [2] - already part of Phobos. Maybe if the language could express head const, it also makes sense to have tail const. [1]: https://github.com/D-Programming-Language/phobos/pull/3862 [2]: http://dlang.org/phobos-prerelease/std_typecons.html#.Rebindable Transitive const is tail const.
Re: Head Const
On Monday, 15 February 2016 at 23:28:28 UTC, Walter Bright wrote: Transitive const is tail const. const(char)[] foo is tail const const(Object) ref is the analog the language is missing so phobos tries to catch up
Re: Speed kills
On Monday, 15 February 2016 at 23:19:44 UTC, Guillaume Piolat wrote: lround and friends have been a big performance problem at times. Everytime you can use cast(int) instead, it's way faster. I didn't know this trick. It generates almost the same sse intruction (it truncates) and has the advantage to be inline-able. Is it documented somewhere ? If not it should.
Re: Head Const
On Monday, 15 February 2016 at 23:28:28 UTC, Walter Bright wrote: On 2/15/2016 3:11 PM, ZombineDev wrote: I'll leave to others to discuss whether a language solution is worth it, but I just wanted to point out there are two library solutions in this area: HeadConst [1] - PR pending, and Rebindable (tail const) [2] - already part of Phobos. Maybe if the language could express head const, it also makes sense to have tail const. [1]: https://github.com/D-Programming-Language/phobos/pull/3862 [2]: http://dlang.org/phobos-prerelease/std_typecons.html#.Rebindable Transitive const is tail const. I used the term "tail const" as a mutable pointer/reference to const/immutable object, where transitivity starts from the object (not from the pointer, which is what currently happens if you type `const Object o`).
Re: Head Const
On 2/15/2016 3:39 PM, ZombineDev wrote: I used the term "tail const" as a mutable pointer/reference to const/immutable object, where transitivity starts from the object (not from the pointer, which is what currently happens if you type `const Object o`). Makes sense.
Re: Head Const
On Monday, 15 February 2016 at 23:39:56 UTC, ZombineDev wrote: On Monday, 15 February 2016 at 23:28:28 UTC, Walter Bright wrote: On 2/15/2016 3:11 PM, ZombineDev wrote: I'll leave to others to discuss whether a language solution is worth it, but I just wanted to point out there are two library solutions in this area: HeadConst [1] - PR pending, and Rebindable (tail const) [2] - already part of Phobos. Maybe if the language could express head const, it also makes sense to have tail const. [1]: https://github.com/D-Programming-Language/phobos/pull/3862 [2]: http://dlang.org/phobos-prerelease/std_typecons.html#.Rebindable Transitive const is tail const. I used the term "tail const" as a mutable pointer/reference to const/immutable object, where transitivity starts from the object (not from the pointer, which is what currently happens if you type `const Object o`). Just to clarify: struct S; const(S)* mutablePointerToS; const(S)[] mutableArrayOfConstObjects; Are examles of tail const. The only missing piece is the ability to have a tail-const references to class objects.
Re: Digital Audio Workstation in D
On Monday, 15 February 2016 at 14:39:38 UTC, Guillaume Piolat wrote: This library exist, the author Aleksey Vaneev is basically a DSP greek semi-god. https://github.com/avaneev/r8brain-free-src By the same author: https://github.com/avaneev/avir Hm, looks like an upsampled sinc filter. Have you compared it to these? https://ccrma.stanford.edu/~jos/resample/Free_Resampling_Software.html
Re: Head Const
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const will do for us: 1. make it easy to interface to C++ code that uses const, as currently it is not very practical to do so, you have to resort to pragma(mangle) 2. supports single assignment style of programming, even if the data is otherwise mutable The downside is, of course, language complexity. so keep const as it is and add headconst?
Re: Head Const
On Mon, Feb 15, 2016 at 11:45:26PM +, ZombineDev via Digitalmars-d wrote: [...] > >I used the term "tail const" as a mutable pointer/reference to > >const/immutable object, where transitivity starts from the object > >(not from the pointer, which is what currently happens if you type > >`const Object o`). > > Just to clarify: > struct S; > const(S)* mutablePointerToS; > const(S)[] mutableArrayOfConstObjects; > > Are examles of tail const. The only missing piece is the ability to > have a tail-const references to class objects. Just out of curiosity, since we already have Rebindable in Phobos and HeadConst is being proposed, what are the disadvantages / shortcomings of a library solution that would justify adding yet another feature to the language? T -- Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
Re: Head Const
On 16/02/2016 9:48 AM, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const will do for us: 1. make it easy to interface to C++ code that uses const, as currently it is not very practical to do so, you have to resort to pragma(mangle) I'd much rather improve pragma(mangle) than add more C++ features to D. 2. supports single assignment style of programming, even if the data is otherwise mutable Like 'final'? We did get rid of that...
Re: Head Const
On Mon, 15 Feb 2016 16:14:23 -0800, H. S. Teoh via Digitalmars-d wrote: > Just out of curiosity, since we already have Rebindable in Phobos and > HeadConst is being proposed, what are the disadvantages / shortcomings > of a library solution that would justify adding yet another feature to > the language? C++ interfacing requires either a well-known type that the compiler special-cases or a builtin attribute. D could ignore this for all purposes besides name mangling, though, and that would be an okay compromise.
Re: Google Summer of Code 2016
On Wednesday, 10 February 2016 at 03:28:55 UTC, Craig Dillabaugh wrote: clip I would like confirmation from the following individuals if they can mentor GSOC this summer. Iain Buclaw Bruno Medeiros Martin Nowak (and as backup Admin) Jacob Ovrum And as backup mentors Adam D. Ruppe Dmitry Olshansky I will continue to polish the Ideas page until the deadline (Feb 18th) http://wiki.dlang.org/GSOC_2016_Ideas but improvements by the community are welcome. GSOC deadline is Friday. Would be great if I could get confirmation from the above individuals if they can still mentor. Also, if you have an interest in being a mentor please let me know, and I can add you to the list. Also improvements to the Idea's page are welcome. I've added a few things (and subtracted one or two), but it still looks a lot like last year's losing effort.
Re: Head Const
On Tue, Feb 16, 2016 at 12:21:38AM +, Chris Wright via Digitalmars-d wrote: > On Mon, 15 Feb 2016 16:14:23 -0800, H. S. Teoh via Digitalmars-d wrote: > > Just out of curiosity, since we already have Rebindable in Phobos > > and HeadConst is being proposed, what are the disadvantages / > > shortcomings of a library solution that would justify adding yet > > another feature to the language? > > C++ interfacing requires either a well-known type that the compiler > special-cases or a builtin attribute. D could ignore this for all > purposes besides name mangling, though, and that would be an okay > compromise. What about besides C++ integration? 'cos I remember some people were complaining that a library solution is bad, but I've forgotten what the reasons were. My thinking is that if the current library solution is bad, or messy, or whatever, and other such library solutions exhibit similar problems, then perhaps what we should be looking at is how to make the language more conducive to implementing nice, usable library solutions to this and a host of other problems, rather than throwing everything and the kitchen sink into the language and end up with an unmaintainable mess. T -- This sentence is false.
Re: Head Const
On 2/15/2016 4:15 PM, Daniel Murphy wrote: 1. make it easy to interface to C++ code that uses const, as currently it is not very practical to do so, you have to resort to pragma(mangle) I'd much rather improve pragma(mangle) than add more C++ features to D. It's currently difficult to interface with C++, and always will be, but smoothing out what we can can be a big opportunity for D. 2. supports single assignment style of programming, even if the data is otherwise mutable Like 'final'? We did get rid of that... Maybe we should resurrect it.
@nogc for structs, blocks or modules?
I am probably the minority but I almost never use the GC in D.
Because I never use the GC I could mark 99% of my functions with
@nogc.
I just seems very annoying to add @nogc to every function.
For people like me it seems that it could be a nice addition to
also allow @nogc for structs like
@nocgc struct Foo{..}
or blocks
@nogc{
void foo(){}
void foo1(){}
}
or even modules
@nogc module Foo
What do you think?
Re: @nogc for structs, blocks or modules?
On Tuesday, 16 February 2016 at 02:42:06 UTC, maik klein wrote:
I just seems very annoying to add @nogc to every function.
you can mark everything as nogc with
// gc functions here
@nogc:
// nogc functions here
void foo() {}
Re: @nogc for structs, blocks or modules?
On Tuesday, 16 February 2016 at 02:47:38 UTC, WebFreak001 wrote:
On Tuesday, 16 February 2016 at 02:42:06 UTC, maik klein wrote:
I just seems very annoying to add @nogc to every function.
you can mark everything as nogc with
// gc functions here
@nogc:
// nogc functions here
void foo() {}
Thanks, this should probably added to
https://dlang.org/spec/attribute.html#nogc
I just realized that I can't even use @nogc because pretty much
nothing in phobos uses @nogc
Re: @nogc for structs, blocks or modules?
On Tuesday, 16 February 2016 at 03:13:48 UTC, maik klein wrote: I just realized that I can't even use @nogc because pretty much nothing in phobos uses @nogc Or it hasn't been tagged @nogc or based on templates they can't be preemptively marked it. I'd think most ranges could be @nogc; And recently with some of the toString's being rewritten to use ranges instead of allocating memory would be @nogc as well. Many algorithms are probably be @nogc too.
Re: Head Const
On Mon, 15 Feb 2016 16:57:44 -0800, H. S. Teoh via Digitalmars-d wrote: > What about besides C++ integration? 'cos I remember some people were > complaining that a library solution is bad, but I've forgotten what the > reasons were. The first problem mentioned was C++ integration, and the minimal thing required to make that work in a nice way is to supply a @cppconst attribute with no semantics that is used only to alter name mangling. It's the least complex solution available. I did get tripped up not too long ago on a lack of a `final` storage class in the context of members. It is sometimes useful. There's also a question of whether we want the same thing for C++ name mangling as for preventing reassignment. It might be clearer to have both final and @cppconst.
Re: @nogc for structs, blocks or modules?
On Tuesday, 16 February 2016 at 03:41:12 UTC, Era Scarecrow wrote: On Tuesday, 16 February 2016 at 03:13:48 UTC, maik klein wrote: I just realized that I can't even use @nogc because pretty much nothing in phobos uses @nogc Or it hasn't been tagged @nogc or based on templates they can't be preemptively marked it. I'd think most ranges could be @nogc; And recently with some of the toString's being rewritten to use ranges instead of allocating memory would be @nogc as well. Many algorithms are probably be @nogc too. templated constructs aren't tagged @nogc because it's inferred, tagging them @nogc would impose restrictions on the end user
Re: Head Const
On Tuesday, 16 February 2016 at 01:04:44 UTC, Walter Bright wrote: On 2/15/2016 4:15 PM, Daniel Murphy wrote: 1. make it easy to interface to C++ code that uses const, as currently it is not very practical to do so, you have to resort to pragma(mangle) I'd much rather improve pragma(mangle) than add more C++ features to D. It's currently difficult to interface with C++, and always will be, but smoothing out what we can can be a big opportunity for D. Hmm, I wonder if Stroustrup said something similar.
Re: @nogc for structs, blocks or modules?
On Tuesday, 16 February 2016 at 03:13:48 UTC, maik klein wrote: Thanks, this should probably added to https://dlang.org/spec/attribute.html#nogc It's actually in there, it's just easy to miss. It's the box with the text after "Attributes are a way to modify one or more declarations. The general forms are: "
Re: Head Const
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const will do for us: 1. make it easy to interface to C++ code that uses const, as currently it is not very practical to do so, you have to resort to pragma(mangle) 2. supports single assignment style of programming, even if the data is otherwise mutable The downside is, of course, language complexity. Straight up head-const is utterly useless IMHO. That's what Java has. C++ has something far more complicated where any individual piece (or pieces) of a pointer type can be declared const without necessarily making the whole thing const. So, _that_ is what we'd need to interact with C++, and it's a downright ugly feature IMHO. Tail-const has some value, because it allows you to refer to a const object with a mutable pointer or reference, whereas head-const just makes things ugly. So, if it weren't for interacting with C++, I would give a resounding "no" to this. It's not even vaguely worth the complexity. As for interoperability with C++, I don't know. Previously, you stated that we weren't going to do things like support interacting with C++ templates (aside from specific instantiations which weren't typed as templates), because it would mean putting a C++ compiler into D, which you didn't want to do. But increasingly, it seems like you're heading in the direction of doing that in an attempt to be able to have fantastic C++ interoperability. On the one on hand, that seems great, since being able to have your C++ code work with your D code is great, but on the other, it seems like it's going to make it so that D is contaminated by a lot of extra C++ muck just to be able to interoperate. At some point, we either need to decide that we're just not going to interoperate with C++ in some manner and lose out on some capability, or we're going to need to fully interoperate with C++ and pretty much put a C++ compiler in the D compiler, and I'd prefer that we didn't go that far. In this particular case, doesn't this really just come down to mangling? It's undefined behavior in D to mutate a const object (even if it was constructed as mutable), so we can't just slap D const on C++ types and have that work, since the C++ code could legally mutate the object. But since C++ considers it defined behavior to mutate a const object by casting away const (or at least it does in all but some very specific cases), can we just get away with the D code treating D const as mutable? If so, then it's purely a matter of mangling. And for that, we could do something like add @cppconst or cppconst that the compiler recognizes and which is only valid in extern(C++) declarations. It would unfortunately have to be more than a simple attribute, because it would have to apply to parts of a parameter's type like C++'s const does (instead of the whole type at once), but if it were implemented such that it was just something that went on the extern(C++) function parameter types (or return types) for mangling purposes, and the D code just treated it as mutable, then it would at least restrict the muck to extern(C++). Now, that does have the downside that the D code has no protection against mutating a C++ object that the C++ code marks as const (whereas while the C++ code can mutate, you at least have to cast away const or use the mutable keyword first), but that seems a whale of a lot better to me than trying to add non-transitive const to D. - Jonathan M Davis
Re: Head Const
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote:
rears its head again :-)
Head Const is what C++ has for const, i.e. it is not
transitive, applies to one level only. D has transitive const.
What head const will do for us:
1. make it easy to interface to C++ code that uses const, as
currently it is not very practical to do so, you have to resort
to pragma(mangle)
2. supports single assignment style of programming, even if the
data is otherwise mutable
The downside is, of course, language complexity.
Maybe you can get away with adding "mutable", which is needed for
intrusive ref counting as well:
C++:
Type * const ptr;
struct ConstType {
mutable int rc;
}
D:
const mutable(Type)* ptr;
struct ConstType {
mutable(int) rc;
}
Re: Head Const
I think the point about name mangling is very true. That's the most important thing, being able to call all of the C++ functions. I personally love that const and immutable are transitive in D. I get annoyed in other languages when I have const objects containing mutable objects, and no real protection from the compiler from stopping the objects in the inside from being mutated. The way I see it, C++ const is a weaker form of const which doesn't complain about mutations enough. I think if we could avoid putting head const in the language, we'd be better off. If you ever really, really need to mutate something inside a const type, you can cast away const. It will rightly look ugly, and the compiler can complain that it's not @safe.
