Re: D Language Foundation Monthly Meeting Summary for December 2022
On 1/28/2023 5:04 AM, Johan wrote: Is there a document describing cases where removal of `@property` does not lead to an error but does lead to a change in behavior of code? No. We are considering a blanket removal of 3000+ instances of `@property`. The resulting compile errors I can fix (unless they happen in speculative instantiations, they may be harder to track down), but I am especially worried about changes in behavior that do not lead to compile warnings/errors. It's been a while, but I think the only difference is if you're taking the address of a property. Without the @property, the address of the function will be taken. With @property, the address of the return value will be taken. This will affect inference, such as `auto x = ` That will likely lead to type mismatch errors further down the line, but I can't guarantee it. The best approach I can recommend is to remove the @propertys a handful at a time, checking them into git, and running your test suite to check for any failures. This will make `git bisect` invaluable in tracking down the cause of any errors that are missed by the test suite.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 28 January 2023 at 13:04:33 UTC, Johan wrote:
Is there a document describing cases where removal of
`@property` does not lead to an error but does lead to a change
in behavior of code?
We are considering a blanket removal of 3000+ instances of
`@property`. The resulting compile errors I can fix (unless
they happen in speculative instantiations, they may be harder
to track down), but I am especially worried about changes in
behavior that do not lead to compile warnings/errors.
Given that the only thing `@property` actually does is change the
result of `typeof` in certain situations, the behavior changes
will probably be things like the following:
```d
static if (typeof(foo.bar) == T) {
// foo has a `T bar` property
} else {
// doesn't have it
}
```
Currently, if `foo` has a `@property T bar();`, this code will
take the first branch. If `@property` is removed, it will take
the second.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote: The December meeting took place on the 3rd of the month at 15:00 UTC. The following people were present: Razvan noted that simplifying the language is part of our vision, and this seems like a good candidate. Walter agreed. Dennis suggested going through DRuntime and Phobos to look at all instances of `@property` and seeing if they could be removed. Walter agreed. Is there a document describing cases where removal of `@property` does not lead to an error but does lead to a change in behavior of code? We are considering a blanket removal of 3000+ instances of `@property`. The resulting compile errors I can fix (unless they happen in speculative instantiations, they may be harder to track down), but I am especially worried about changes in behavior that do not lead to compile warnings/errors. Thanks a lot, Johan
Re: D Language Foundation Monthly Meeting Summary for December 2022
On 1/23/2023 11:21 PM, Siarhei Siamashka wrote: But the safety is not exactly great. It does (and always has) resolved the #1 memory safety problem - buffer overflows. If you use @safe, and the GC for allocations, it is just as memory safe as Python.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote: Robert thinks Rust has won that game. We're the second person to the moon. Do you mean second to last? The safety offered by D language currently only looks good when compared to C/C++, but is worse than pretty much any of the other popular/mainstream languages. D language even did not invent memory safety, because the other safe languages existed long before it (such as Python, etc.). The strong point of D language is a convenient syntax combined with full native speed of compiled binaries. And also compilation speed for those who care about it. But the safety is not exactly great. And compatibility breaking habits are also bad. D can't realistically compete with Rust on the safety front and with C/C++ on the compatibility front. Put `@safe` on top, disallow taking addresses of the stack, don't allow returning `ref`, and don't allow pointer arithmetic. That's as safe as we need to be. I like this proposal. Will it actually happen?
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Monday, 23 January 2023 at 21:26:56 UTC, H. S. Teoh wrote:
On Mon, Jan 23, 2023 at 08:43:03PM +, Adam D Ruppe via
Digitalmars-d-announce wrote:
On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
> There should be a tool for auto-generating JS wrappers,
> perhaps even HTML snippets, so that a user literally can
> just write:
>
> import std; // OK, maybe import std.wasm or something
>void main() { writeln("Hello, world!");
> and get a webpage that prints that message in a browser
> window
> without writing a single line of JS or HTML.
http://webassembly.arsdnet.net/
Paste in
import std.stdio;
void main() { writeln("hello world"); }
to the box on that page
and get
http://webassembly.arsdnet.net/usertemp
Ahahahaha... just like Adam to have already dunnit while I'm
still twiddling my fingers wondering how to go about doing it.
:-D Now all we need is to package your little page up into a
dub package or something (personally I prefer just a tarball)
and we're good to go. :-D
Webassembly is a trash target but like been there done that.
Yeah TBH after dabbling with it a little I realized just how
much it was still dependent on JS to do the heavy lifting. You
can't even pass strings across the JS/WASM boundary without
truckloads of JS boilerplate. The C-like API isn't officially
part of the WASM standard yet, and they're still trying to
figure out how GC might work. As far as I'm concerned, it's
still early adopter tech, not yet stable enough for me to
invest in.
Of course there are some caveats in what works, there have
been come contributions coming in from hipreme recently to
extend it a lil.
Nice. Can it handle WebGL yet? I betcha that'd be the second
question a newbie to D would ask after asking about WASM. :-P
T
I was going to wait a little bit on that announcement. But yes,
Hipreme Engine has already been completely ported to WASM. File
loading, rendering with my abstraction, audio playing,
image/audio decoding, input system, I've got pretty much
everything working. WASM only changed in my engine how the file
loading is handled internally. An example, It sends D delegates
to JS execute when things are complete, so, there isn't anymore a
sync API for loading files.
I have used arsd.cgi for making it easy to any D programmer host
it with dub. I have posted on Learn like yesterday how to
integrate the custom runtime with any dub project too, which is
how I'm using to build for my engine.
The list of features being supported are:
- new
- string switch
- classes (inheritance and abstract included)
- interfaces
- every array operation
- every associative array operation
- RAII
- delegates and function pointers
- assertion
- throw should work. Catching don't
- RTTI (typeid and other things that depends on it)
- All the compile time features seems to be working finely
- main() and it will run as expected.
- string utf decoding
Unsupported features:
- static this/~this (should be easy to implement though, my
engine has no need to do that, specially since it uses a lot of
DLL for Android and Xbox and static this is quite buggy for it
anyway)
- try/catch
- fibers
The problem on try/catch/fiber are the same. They need stack
unwinding and from what I've looked, this implementation needs
compiler developers to write a little of assembly to get this
working, as I have no idea on how that works, I can't implement
that.
I believe this covers like 90% the usage of one using the
druntime.
I honestly don't care about throw/catch. Specially for gamedev
which is my aim, the code doesn't need to "protect" from itself.
That being said, if one is not using Hipreme Engine and is using
a lot of standard library, this one would need to implement a lot
of it. Hipreme Engine implements a minimal phobos (as I don't
implement the entire libc) for being used. Needless to say, some
modules from phobos didn't need to adapt to WASM, so,
`std.algorithm` and `std.traits` are being used from upstream.
std.math was possible to copy/paste without too much work to do
(A matter of 5 lines I think).
I'm also using arsd.ttf to runtime create text textures, a
library which does not uses any of my modules, no bug was found
on it, so, this is mostly a matter of giving a little of effort
and everything can be done.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Mon, Jan 23, 2023 at 08:43:03PM +, Adam D Ruppe via
Digitalmars-d-announce wrote:
> On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
> > There should be a tool for auto-generating JS wrappers, perhaps even
> > HTML snippets, so that a user literally can just write:
> >
> > import std; // OK, maybe import std.wasm or something
> > void main() { writeln("Hello, world!");
> > and get a webpage that prints that message in a browser window
> > without writing a single line of JS or HTML.
>
> http://webassembly.arsdnet.net/
>
> Paste in
> import std.stdio;
> void main() { writeln("hello world"); }
>
> to the box on that page
>
> and get
> http://webassembly.arsdnet.net/usertemp
Ahahahaha... just like Adam to have already dunnit while I'm still
twiddling my fingers wondering how to go about doing it. :-D Now all we
need is to package your little page up into a dub package or something
(personally I prefer just a tarball) and we're good to go. :-D
> Webassembly is a trash target but like been there done that.
Yeah TBH after dabbling with it a little I realized just how much it was
still dependent on JS to do the heavy lifting. You can't even pass
strings across the JS/WASM boundary without truckloads of JS
boilerplate. The C-like API isn't officially part of the WASM standard
yet, and they're still trying to figure out how GC might work. As far as
I'm concerned, it's still early adopter tech, not yet stable enough for
me to invest in.
> Of course there are some caveats in what works, there have been come
> contributions coming in from hipreme recently to extend it a lil.
Nice. Can it handle WebGL yet? I betcha that'd be the second question
a newbie to D would ask after asking about WASM. :-P
T
--
I see that you JS got Bach.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On 1/23/23 12:06, H. S. Teoh wrote:
> `.parallel` -- it's basically zero cost. And for script-like helper
> utilities, .parallel is just the thing you need to get the job done in
> the shortest amount of time possible. No need for anything more
> elaborate.
Yes! :)
As a heads up to those who haven't tried it yet, there are cases that
may benefit from reducing the work unit size from its default value of 100.
Especially when it's about file processing and there are a few files
that take disproportionate amount of processing time, then the thread
that is working on the largest file(s) would be holding on to 99 others
to process them later in serial fashion. This may happen when the other
e.g. 20 threads have already finished their tasks.
So, I recommend experimenting with smaller work unit sizes; I currently
use 1 for such file processing. Something like this:
auto tp = new TaskPool(totalCPUs / 2); // Thread count
foreach (e; tp.parallel(elements, 1)) { // Work unit size
// ...
}
tp.finish(); // Don't forget
as seen here:
https://youtu.be/dRORNQIB2wA?t=1692
Ali
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
There should be a tool for auto-generating JS wrappers, perhaps
even HTML snippets, so that a user literally can just write:
import std; // OK, maybe import std.wasm or something
void main() { writeln("Hello, world!");
and get a webpage that prints that message in a browser window
without writing a single line of JS or HTML.
http://webassembly.arsdnet.net/
Paste in
import std.stdio;
void main() { writeln("hello world"); }
to the box on that page
and get
http://webassembly.arsdnet.net/usertemp
Webassembly is a trash target but like been there done that.
Of course there are some caveats in what works, there have been
come contributions coming in from hipreme recently to extend it a
lil.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Sat, Jan 21, 2023 at 04:29:28AM +, Mike Parker via
Digitalmars-d-announce wrote:
[...]
> __CTFE writeln__
>
> Razvan next brought up [a PR to implement a `__ctfeWriteln`
> built-in](https://github.com/dlang/dmd/pull/12412). It was currently
> stalled and needed Walter's approval. Walter asked Razvan to email him
> about it. He subsequently approved it.
This may seem like a small item, but it's a landmark!! The first PR for
this was submitted back in 2011 (https://github.com/dlang/dmd/pull/296),
superceded in in 2012 (https://github.com/dlang/dmd/pull/692), revived
in 2016 (https://github.com/dlang/dmd/pull/6101), re-attempted in 2017
(https://github.com/dlang/dmd/pull/7082), submitted in its present form
in Apr 2021 (https://github.com/dlang/dmd/pull/12412), and finally
approved in Dec 2022. This is monumental!
OTOH, it begs the question, is there any way to improve our present
process so that relatively small features like these don't take 11 years
to get implemented?
[...]
> ### Ali
> Ali reported that he had finished the new D program at work he had
> [told us about in the November
> meeting](https://forum.dlang.org/thread/citxnklerlvqmybyo...@forum.dlang.org).
> It had uncovered a performance issue with `std.file.dirEntries`. As
> for the program, he was happy with the end result.
>
> He said he'd used `std.parallelism.parallel` again and speculated he's
> probably among the people who've used it most. He said it helps
> tremendously. It's very simple and everything becomes very fast.
Just wanted to chime in here to say that std.parallelism.parallel is
absolutely awesome, and I've been using it in a few of my projects for
what amounts to instant speed-up "for free".
The original design hit jackpot in making it as easy as possible to turn
a regular foreach loop into a parallel loop: just add .parallel to your
aggregate. This makes it trivial to test the performance gains of
parallelizing any given foreach loop (with independent iterations, of
course). You didn't have to invest a ton of time writing code to
instantiate task managers, task pools, create threads, manage threads,
wait for them to finish, etc.. For highly-specific performance tweaks,
you'd probably want to do all that, but for one-off quick evaluations of
whether a parallel approach is even worth it in the first place, the
design of .parallel is exactly the thing needed. Once you've confirmed
it works, you can, if needed, invest more effort into managing task
pools, etc.. If not, you haven't wasted any effort except writing
`.parallel` -- it's basically zero cost. And for script-like helper
utilities, .parallel is just the thing you need to get the job done in
the shortest amount of time possible. No need for anything more
elaborate.
[...]
> ### Walter
[...]
> He then said that he had noticed in discussions on HN and elsewhere a
> tectonic shift appears to be going on: C++ appears to be sinking.
> There seems to be a lot more negativity out there about it these days.
> He doesn't know how big this is, but it seems to be a major shift.
> People are realizing that there are intractable problems with C++,
> it's getting too complicated, they don't like the way code looks when
> writing C++, memory safety has come to the fore and C++ doesn't deal
> with it effectively, etc.
The inevitable is happening. Has been happening, just on a smaller
scale. But it will only grow.
[...]
> Robert thinks Rust has won that game. [...] Rust is also taking over
> some of the web world because it compiles easily to web assembly.
LDC already compiles to WASM. It's a crucial first step. But the
usability level of D in WASM is currently wayyy below what it would take
to win people over. If we want to win this game, we need to get WASM
support to the point that you could in theory just recompile a D program
and have it work in WASM without any change. Well, excepting, of
course, stuff that WASM fundamentally can't do.
Currently, you can compile individual functions, but you can't have
main(), you can't use Phobos, you can't use the GC, and you need to
write a lot of JS boilerplate to have your WASM D code interact with
anything outside its own little bubble. Strictly speaking this isn't
D's problem, but that's cold comfort for anyone who wants to develop for
WASM in D. Yeah, writing JS and HTML is part-and-parcel of targeting
WASM, but why can't we make our packaging better? There should be a
tool for auto-generating JS wrappers, perhaps even HTML snippets, so
that a user literally can just write:
import std; // OK, maybe import std.wasm or something
void main() { writeln("Hello, world!");
and get a webpage that prints that message in a browser window without
writing a single line of JS or HTML. All the JS boilerplate and HTML
tedium should be automatically taken care of, unless the user overrides
something.
Using WASM with D should be on the level of usability of appending
.parallel to your aggregate to
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote: Robert spoke up then to suggest deprecating @property and releasing a tool that removes it from a code base. Then we should apply that tool to create pull requests for all dub packages using @property, and then in a future release, we kill it. Anyone affected by the removal can then run the tool on their own code. He added that we should do this with any feature we decide to remove. This is the modern way of software development: you don't just break someone's code, you break their code and give them a tool to fix it. I agree with that 100%, perhaps the feature should be built in into DUB, it can already detect the compilers and its version, so it can do all the heavy lifting already Compile times keep getting slower. Why doesn't an LSP implementation come with DMD? Why don't we have a compiler daemon? Why aren't his build times sub one second? All my projects fully recompile in around 1s, i am sad when i see libraries that tank the compile speed to multiple seconds.. I ended up writing my own runtime and my own std, this is why i advocate for language enhancements rather than putting more template soup into the std And i agree even more on the language server, Jan did an amazing work with serve-d, but it highlights 2 problems: - slow to compile, wich makes contributing a pain - DCD is basically too basic, doesn't even support most D features including templates SumType is really awesome, and we should really do something with it. I agree, SumType is a great piece of library, it should be promoted as a language feature The first involved dub's settings file, settings.json. As he put it, have you ever seen a program that asked you to write its settings using JSON? There had been some favorable responses to the idea of moving to YAML from some core contributors a few years back. It just needed someone to do it. He asked if we were okay with the move. Átila said we probably shouldn't keep JSON, but wondered if YAML was the best choice. What about TOML? This sparked a minor bikeshedding discussion, but there was no major opposition to Mathias's plan. (He has since opened a draft PR. Sönke Ludwig wants to see a broader discussion of this before finalizing it, so I expect Mathias will ask for community feedback at some point.) I agree, json is not a good file format, it doesn't even support comments and is annoying to parse A simple ini file would be 10x better already, no need complicated parsers like YAML or TML Robert thinks Rust has won that game. We're the second person to the moon. Put @safe on top, disallow taking addresses of the stack, don't allow returning ref, and don't allow pointer arithmetic. That's as safe as we need to be. D's niche is on top of Rust and under TypeScript. That's where we need to be. That may not be the most popular opinion in the group, but he was alone in his room and no one could hurt him. He thinks C++ has been sinking, but it's probably going to keep sinking until he's dead and will never sink completely, but Rust will take that over. Rust is also taking over some of the web world because it compiles easily to web assembly. I DISAGREE fully, Rust has not won "that game", there is a similar negative sentiment about rust, "too complicated", "too hard", "bad syntax", "slow to compile", etc The future will be many languages, each being best at certain domains, we seen it with the rise of Go, doing what it do best with the cli/web/server/containers and nothing else WASM? C/C++ won the game, Abobe is the perfect example, it's not simple hello world Rust people are doing, it's full commercial projects https://web.dev/ps-on-the-web/ Same with games
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 11:25:37 UTC, Sergey wrote: On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote: The December meeting took place on the 3rd of the month at 15:00 UTC. The following people were present: * Andrei Alexandrescu * Walter Bright * Ali Çehreli * Dennis Korpel * Mathias Lang * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek Thank you Mike and all D foundation. It was very pleasant read. I am surprised how many things and details were discussed in an hour and a half! Agreed 100%, these summaries and the transparency into the decision making are great!
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
As far as he understood, the only time `@property` has an
effect is when you take the address of a function it annotates.
It is when you do typeof(thing.prop), not
Walter said that `__traits` is meant to be ugly.
We should revisit this decision. I don't think it ever made
sense, and especially now with the benefit of hindsight it looks
like a clear unforced error.
Robert said that doesn't solve his problem with compile times.
He has a project that doesn't use much of Phobos, but compile
times still suffer. The compiler is slow.
I'd like to know more about this project
He had previously dug into `hasUDA` and it was scary how many
recursive expansions he found.
We should also revisit the abstractions here. The more I use
these the more I've been landing on something like what Steve
described in the dconf online. It is faster to compile, more
flexible with runtime reuse, and just generally easier to
document and use.
Then we can just let hasUDA and friends die.
That goes to the idea of caching or pre-compiling the template
so that
Please note that the compiler does cache templates right now, and
it takes gigs of memory. A lot of work would have to be done to
make this good since work not done is still better than work
unnecessarily done... and if it is cached too aggressively you
just run out of memory.
If the end result is simple, we ought to be able to discard
intermediate results, but the current implementation doesn't even
allow this!
We don't have [...] `std.html` [...] We just need someone to
write them.
Yes, if only some did that 13 years ago and has been continuously
maintaining it ever since. If only ~someone~ wrote that.
Something was causing the struct configuration to take over 10
minutes to compile.
If you did any string replacements that'd slaughter your
performance, the ctfe engine is *extremely* bad at this.
In my arsd.jni, I had a string like:
enum code = q{
PRETEND_MACRO void foo() { implementation; }
};
mixin(code.replace("PRETEND_MACRO", ""));
mixin(code.replace("PRETEND_MACRO", "static"));
Those two simple lines added 30 seconds to the compile time! Just
copy/pasting it and replacing the pretend macro ahead of time cut
95% of the build time off. It was astonishing.
You can optimize some of these with mutable buffers, avoid the
concat operator in ctfe even if it means two passes through the
data. This helps a lot.
But also just using template mixins tends to work well when you
know the proper techniques.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote: The December meeting took place on the 3rd of the month at 15:00 UTC. The following people were present: * Andrei Alexandrescu * Walter Bright * Ali Çehreli * Dennis Korpel * Mathias Lang * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek Thank you Mike and all D foundation. It was very pleasant read. I am surprised how many things and details were discussed in an hour and a half!
Re: D Language Foundation Monthly Meeting Summary for December 2022
A very big problem we have right now is that we are on pretty shaky foundations with how symbols are represented at the binary image level due to DLL's not be fully implemented in dmd. Any work for things like incremental compilation must be done with the knowledge that the foundations right now are just not there to do this reliably cross platform. I.e. is incredibly easy to run into: https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4217?view=msvc-170 I believe we are going to have to modify export (and with that removing it as a visibility modifier) quite significantly. In the C/C++ world you can use macros and compiler level defines to swap out DllImport and DllExport, or remove it all together. We can't do that. Which means we are going to need to make export a whole lot smarter if we don't want to run into these issues on Windows.
D Language Foundation Monthly Meeting Summary for December 2022
The December meeting took place on the 3rd of the month at 15:00 UTC. The following people were present: * Andrei Alexandrescu * Walter Bright * Ali Çehreli * Dennis Korpel * Mathias Lang * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek The meeting lasted around an hour and a half. ## The summary ### Dennis Dennis opened by reporting that he had begun working on a DIP to use `@default` as a means of resetting attributes. He had a question about what it should affect: should it reset all attributes (including visibility attributes like `private`), or only function attributes? The unanimous consensus was that it should only affect function attributes. He has since [submitted the DIP for Draft Review](https://github.com/dlang/DIPs/pull/236). ### Razvan __@property__ In his ongoing effort to resolve old Bugzilla issues, Razvan had encountered a number of old issues regarding `@property`. Walter and Andrei had said in the past that we shouldn't support the feature anymore, and it's often recommended that people not use it. But people do still use it. So what are we going to do about it? Should we attempt to fix these old issues? Should we deprecate `@property`? Walter suggested one possible approach is just to leave it as is. Those who see a benefit in using it can continue to do so, and those who don't can avoid it. He hadn't looked into the issues surrounding `@property` in a long time and asked if this was a viable approach. As far as he understood, the only time `@property` has an effect is when you take the address of a function it annotates. Razvan said `@property` sometimes interacts with other features in unexpected ways and the spec says nothing about what it's supposed to do. Maybe we could just add something to the spec saying it shouldn't be used. Andrei said that's not what a spec is supposed to do. A spec tells you what happens when you, e.g., move your hand like this. A spec doesn't give you advice. If we're keeping it, we should spec it out even if we then never touch it again. Guides will say whether or not to use it. But we can't just leave it hanging unspecified. Ali noted that he didn't include it in his book other than to say using it is discouraged. Razvan asked how he should handle these `@property` issues in Bugzilla. Find someone to fix them or just document the behavior? Walter said the latter. He also suggested adding a recommendation to avoid `@property` in the best practices section of the documentation. Robert spoke up then to suggest deprecating `@property` and releasing a tool that removes it from a code base. Then we should apply that tool to create pull requests for all dub packages using `@property`, and then in a future release, we kill it. Anyone affected by the removal can then run the tool on their own code. He added that we should do this with any feature we decide to remove. This is the modern way of software development: you don't just break someone's code, you break their code and give them a tool to fix it. Átila said that would work fine here except in cases where someone is taking the address of an `@property` function. We aren't going to be able to make a tool for that. Robert said that's true but do it anyway. The tool should tell them, "This doesn't work for this case. Sorry." He said that if we test the tool with all the D code we can find on GitHub, he'd bet beers at DConf that we'd find no more than ten instances of code that would break. After more discussion in a similar vein, Razvan said what it comes down to is that this is a broken feature and we don't know how to fix it. We need to just deprecate it. We shouldn't be keeping broken features around if we aren't going to fix them. Robert agreed. A tool to remove it from code will handle most cases, and for those people whom it doesn't help we'll have to help them migrate. There was then some discussion about whether or not `@property` is fixable. Dennis brought up the case of when the property is a callable (and linked the [docs for Adam Ruppe's `arsd.jsvar` module](http://arsd-official.dpldocs.info/arsd.jsvar.html) as an example of the problem manifesting; see Adam's comment in the example code and his notes near the bottom of the page). If we want to support this kind of type that can store callables, then we need some kind of fix. Walter said that's an ambiguity for which no one had been able to settle on a solution. Andrei said one intent of `@property` is to be a replacement for a data member. That's a good goal. Any improvement of `@property` should serve that purpose. If there's an ambiguity, it should go in favor of that. Átila thought that made sense. If there's an ambiguity, then just pretend it's a field. If there's only one set of parentheses, you call the callable. If there are no parentheses, you call the callable. Robert countered by saying we're trying to make D simpler, and `@property`
