It seems like I managed to solve it.
All the chain of properties now capturing a generic value type T.
And finally the most inner associative array will handle the
implicit cast.
Maybe that extra implicit () got confused when the types are
same, but the aliases to those types are different. o.O
property it is just plain broken and has been the whole
time.
Don't expect it to ever be fixed.
At least my 5 hour trying-and-failing session comes to a logical
end here :D
Thank You!
temp variable or inside a with(), then both
form works ok.
Bit when I try to write the whole thing in a single nice
expression: No property `_size` for the type `void`.
In the documentation I see this:
- For the expression typeof(exp) where exp is an @property
function, the type is the return
On Friday, 26 May 2023 at 21:00:20 UTC, realhet wrote:
Only the extra () let it compile successfuly.
No way to fix it. If the function takes an extra argument you can
kinda trick it but for zero arg function pointer return from a
property it is just plain broken and has been the whole time
he type of this is BlobLoader
'lod0' is a mixin generated @property getter. It calls a template
function in the karcSamples class: _getBlob!"lod0"(key) this
also calls an internal struct called DataLoggerBlobAA which is
acting like an associative array. That iternal stru
On Friday, 19 August 2022 at 16:36:24 UTC, MyNameHere wrote:
On Friday, 19 August 2022 at 14:30:50 UTC, kinke wrote:
Oh and `DevicePath()` is a convenience member returning a
pointer to the 'dynamic array' (as the array decays to a
pointer in C too), so no need to fiddle with `.offsetof` and
c
On 8/19/22 12:36 PM, MyNameHere wrote:
On Friday, 19 August 2022 at 14:30:50 UTC, kinke wrote:
Oh and `DevicePath()` is a convenience member returning a pointer to
the 'dynamic array' (as the array decays to a pointer in C too), so no
need to fiddle with `.offsetof` and computing the pointer ma
On Friday, 19 August 2022 at 14:30:50 UTC, kinke wrote:
Oh and `DevicePath()` is a convenience member returning a
pointer to the 'dynamic array' (as the array decays to a
pointer in C too), so no need to fiddle with `.offsetof` and
computing the pointer manually.
I am using ```-BetterC```, so
On Friday, 19 August 2022 at 13:49:08 UTC, MyNameHere wrote:
Thank you, that seems to have resolved the issue, though I wish
these sorts of problems would stop cropping up, they are
souring the experience with the language.
Oh and `DevicePath()` is a convenience member returning a pointer
to
On Friday, 19 August 2022 at 14:22:04 UTC, Steven Schveighoffer
wrote:
On 8/19/22 9:49 AM, MyNameHere wrote:
Thank you, that seems to have resolved the issue, though I
wish these sorts of problems would stop cropping up, they are
souring the experience with the language.
Most likely that "mem
On 8/19/22 9:49 AM, MyNameHere wrote:
Thank you, that seems to have resolved the issue, though I wish these
sorts of problems would stop cropping up, they are souring the
experience with the language.
Most likely that "member" is a macro in C. D doesn't have macros, so it
uses properties.
T
Thank you, that seems to have resolved the issue, though I wish
these sorts of problems would stop cropping up, they are souring
the experience with the language.
It's a method returning a `CHAR*` - `_DevicePath` is the actual
member. I guess it's a dynamically sized struct, which cannot be
mapped directly to D, hence this representation.
I am receiving this error:
```
Error: no property `offsetof` for type `char*`
```
from this snippet:
```d
import core.sys.windows.setupapi;
void main() {
SP_DEVICE_INTERFACE_DETAIL_DATA_A DeviceInterfaceDetail;
uint Offset = DeviceInterfaceDetail.DevicePath.offsetof;
}
```
You may
On 12/15/21 9:41 AM, Stanislav Blinov wrote:
On Wednesday, 15 December 2021 at 11:36:41 UTC, Manfred Nowak wrote:
On Tuesday, 14 December 2021 at 08:28:01 UTC, WebFreak001 wrote:
[...]
Alternatively, remove the template `()` from your `struct Header`
What is the semantic sense of a template h
On Wednesday, 15 December 2021 at 11:36:41 UTC, Manfred Nowak
wrote:
On Tuesday, 14 December 2021 at 08:28:01 UTC, WebFreak001 wrote:
[...]
Alternatively, remove the template `()` from your `struct
Header`
What is the semantic sense of a template having no parameters?
Although the documentati
On 12/15/21 6:36 AM, Manfred Nowak wrote:
On Tuesday, 14 December 2021 at 08:28:01 UTC, WebFreak001 wrote:
[...]
Alternatively, remove the template `()` from your `struct Header`
What is the semantic sense of a template having no parameters?
Although the documentation declares such a template
On Wednesday, 15 December 2021 at 11:36:41 UTC, Manfred Nowak
wrote:
On Tuesday, 14 December 2021 at 08:28:01 UTC, WebFreak001 wrote:
[...]
Alternatively, remove the template `()` from your `struct
Header`
What is the semantic sense of a template having no parameters?
Although the documentati
On Wednesday, 15 December 2021 at 11:36:41 UTC, Manfred Nowak
wrote:
On Tuesday, 14 December 2021 at 08:28:01 UTC, WebFreak001 wrote:
[...]
Alternatively, remove the template `()` from your `struct
Header`
What is the semantic sense of a template having no parameters?
Although the documentati
On Tuesday, 14 December 2021 at 08:28:01 UTC, WebFreak001 wrote:
[...]
Alternatively, remove the template `()` from your `struct
Header`
What is the semantic sense of a template having no parameters?
Although the documentation declares such a template to be
syntactically correct, not a single
On Tuesday, 14 December 2021 at 08:12:04 UTC, zoujiaqing wrote:
My code:
```D
module http.HttpRequest;
import std.container;
import std.array : Appender;
struct HttpRequest
{
struct Header()
{
Appender!string name;
Appender!string value;
}
string method;
st
My code:
```D
module http.HttpRequest;
import std.container;
import std.array : Appender;
struct HttpRequest
{
struct Header()
{
Appender!string name;
Appender!string value;
}
string method;
string uri;
int versionMajor = 0;
int versionMinor = 0;
On Saturday, 4 September 2021 at 23:57:09 UTC, jfondren wrote:
You're returning a copy of a slice, so if this compiled nothing
useful would happen anyway. This works if `whatever()` returns
`ref dstring` instead, with no other changes. Search
https://dlang.org/spec/function.html for 'lvalue' a
On Saturday, 4 September 2021 at 23:33:39 UTC, someone wrote:
```d
public class cSomething {
private:
dstring pstrWhatever = null;
public:
@safe dstring whatever() { return pstrWhatever; }
@safe void whatever(const dstring lstrWhatever) {
pstrWhatever = lstrWhatever; }
}
vo
```d
public class cSomething {
private:
dstring pstrWhatever = null;
public:
@safe dstring whatever() { return pstrWhatever; }
@safe void whatever(const dstring lstrWhatever) { pstrWhatever
= lstrWhatever; }
}
void main() {
cSomething lobjSomething = new cSomething();
default property can be another object altogether. The
best use case I can think of is a default collection for a
class such as lobjComputers.computers in my example.
That really isn't what alias this is used for commonly. I.e.
I didn't know alias this even existed a month ago s
On Sunday, 8 August 2021 at 04:51:48 UTC, someone wrote:
On Sunday, 8 August 2021 at 04:30:12 UTC, rikki cattermole
wrote:
So a field that will automatically be resolved to as part of
the behavior of generated toString methods.
No. A default property can be another object altogether. The
On Sunday, 8 August 2021 at 04:30:12 UTC, rikki cattermole wrote:
So a field that will automatically be resolved to as part of
the behavior of generated toString methods.
No. A default property can be another object altogether. The best
use case I can think of is a default collection for a
So a field that will automatically be resolved to as part of the
behavior of generated toString methods.
That really isn't what alias this is used for commonly. I.e.
struct ValueReference {
private {
SomethingElse* impl;
}
bool isNull() { return impl is
you, I mean the community, think is it a good idea
to file a DIP to eventually get a new attribute to
unambiguously label a class' default property ?
Can you please explain what a "default property" is? I have
never encountered such a thing in any other programming
language.
P to eventually get a new attribute to unambiguously
label a class' default property ?
Can you please explain what a "default property" is? I have never
encountered such a thing in any other programming language.
label a class' default property ?
eg: @default string whatever(...);
eg: @default @property string whatever(...); /// if @property
survives; that is
... or whatever you consider it should be named ?
Besides, alias this was not implemented to handle default
properties albeit it seems it is co
On Friday, 9 July 2021 at 11:04:23 UTC, Dennis wrote:
On Friday, 9 July 2021 at 10:19:59 UTC, Виталий Фадеев wrote:
It possible in current version 2.097 ?
If you `import std.typecons` you can do:
```D
element.border = tuple(1, solid).expand;
```
But it's not pretty. I suggest either calling t
On Friday, 9 July 2021 at 10:19:59 UTC, Виталий Фадеев wrote:
It possible in current version 2.097 ?
If you `import std.typecons` you can do:
```D
element.border = tuple(1, solid).expand;
```
But it's not pretty. I suggest either calling the function
regularly, or combing all settings in a si
On Friday, 9 July 2021 at 10:19:59 UTC, Виталий Фадеев wrote:
I want this feature in D:
```
element.border = 1, solid;
struct Element
{
@property
void border( int width, BorderStyle style )
{
this.borderWidth = width;
this.borderStyle = style;
}
}
```
Description
I want this feature in D:
```
element.border = 1, solid;
struct Element
{
@property
void border( int width, BorderStyle style )
{
this.borderWidth = width;
this.borderStyle = style;
}
}
```
Description:
```
element.border = 1, solid;
```
will rewriten to the
On Tuesday, 6 July 2021 at 10:06:11 UTC, Jack Applegame wrote:
Here's another way using ``` std.typecons ```
```d
import std.stdio;
import std.typecons;
alias input = Typedef!int; //new code
struct Field {
void opAssign(int a) {
writefln("Field.opAssign(%s)", a);
}
}
struct R
On Tuesday, 6 July 2021 at 15:24:37 UTC, jfondren wrote:
3. https://run.dlang.io/is/AJM6Vg - hybrid where ClockAssign
has an unsafe pointer that the compiler complains about :/
4.
```d
import std.stdio;
struct Field {
void opAssign(int a) {
writefln("Field.opAssign(%s)", a);
}
On Tuesday, 6 July 2021 at 10:06:11 UTC, Jack Applegame wrote:
How to disable `register.clock = 10;` but allow
`register.clock(1) = 10;`?
I want to get a compilation error on `register.clock = 10;`
Some options:
1. return a temporary struct with an opIndex
```d
import std.stdio;
struct Fiel
ch a disruptive change has
passed. For better or worse we have the half-implemented near-useless
meaning of `@property`, and basically it's unneeded.
-Steve
On Tuesday, 6 July 2021 at 13:27:43 UTC, Jack Applegame wrote:
And that's sad. It should happen for properties only.
Totally disagree. This is one of my favorite D features.
On Tuesday, 6 July 2021 at 12:33:20 UTC, Adam D Ruppe wrote:
The language always allows `a = b;` to be rewritten as `a(b);`.
And that's sad. It should happen for properties only.
On Tuesday, 6 July 2021 at 10:06:11 UTC, Jack Applegame wrote:
How to disable `register.clock = 10;`
You don't. The language always allows `a = b;` to be rewritten as
`a(b);`.
Best you can do is use different types for the two arguments.
Maybe clock could take a struct Clock { int x; } or s
On Tuesday, 6 July 2021 at 10:25:28 UTC, Dennis wrote:
We're [still awaiting formal assessment on
dip1038](https://forum.dlang.org/thread/sojvxakgruzfvbigz...@forum.dlang.org), but if that gets in, you can mark `clock` or `Field` `@nodicard`. Otherwise I don't know of a way.
Yes, it would help.
On Tuesday, 6 July 2021 at 10:06:11 UTC, Jack Applegame wrote:
How to disable `register.clock = 10;` but allow
`register.clock(1) = 10;`?
I want to get a compilation error on `register.clock = 10;`
We're [still awaiting formal assessment on
dip1038](https://forum.dlang.org/thread/sojvxakgruzf
On Tuesday, 6 July 2021 at 10:24:45 UTC, drug wrote:
Something like using different types for arguments in
`Register.clock` and `Field.opAssign`?
I've been thinking about it. Unfortunately, this is not always
convenient.
06.07.2021 13:06, Jack Applegame пишет:
Code:
```d
import std.stdio;
struct Field {
void opAssign(int a) {
writefln("Field.opAssign(%s)", a);
}
}
struct Register {
Field clock(int a) {
writefln("Register.clock(%s)", a);
return Field();
}
}
void m
Code:
```d
import std.stdio;
struct Field {
void opAssign(int a) {
writefln("Field.opAssign(%s)", a);
}
}
struct Register {
Field clock(int a) {
writefln("Register.clock(%s)", a);
return Field();
}
}
void main() {
Register register;
register.cloc
On Monday, 7 June 2021 at 16:10:08 UTC, Jack wrote:
I think you meant to implement ranges? you can implement in the
way you wanted: ```foreach(lobjComputer; lobjComputers)``` ...
Thanks for your reply !
I am aware that ranges are one of D's gems, I did take an
overview of them last night or t
public classComputer[] computers; alias computers this; ///
ie: default property
}
```
It seems it works perfectly well.
Also, your:
```d
alias computers this;
```
was very clever, indeed :)
On Monday, 7 June 2021 at 15:26:27 UTC, someone wrote:
Consider the following code:
```d
class classComputer {
private string pstrName;
final @property string name() { return this.pstrName; }
final @property void name(in string lstrName) {
this.pstrName = lstrName; }
this
}
>
>public classComputer[] computers; /// how can I tag this as the default
> property ?
alias computers this;
>
> }
>
> void main (
>
>) {
>
>classComputers lobjComputers = new classComputers;
>lobjComputers.computers ~= new classComputer
Consider the following code:
```d
class classComputer {
private string pstrName;
final @property string name() { return this.pstrName; }
final @property void name(in string lstrName) { this.pstrName
= lstrName; }
this(
string lstrComputerName
) {
this.pstrName
On Sunday, 16 May 2021 at 15:47:55 UTC, Adam D. Ruppe wrote:
On Sunday, 16 May 2021 at 15:12:25 UTC, Nick wrote:
Is this warning still valid?
The @property thing doesn't do much. All it does is change
typeof(a.prop) from function over to the return value of the
function. (Which act
On Monday, 17 May 2021 at 14:56:21 UTC, Steven Schveighoffer
wrote:
It used to be required, but we removed that requirement a long
time ago.
yeah i remember ElementType required it last time i checked but
that was a while ago
indeed it is all fixed now
On 5/16/21 11:47 AM, Adam D. Ruppe wrote:
On Sunday, 16 May 2021 at 15:12:25 UTC, Nick wrote:
Is this warning still valid?
The @property thing doesn't do much. All it does is change
typeof(a.prop) from function over to the return value of the function.
(Which actually makes it require
On Sunday, 16 May 2021 at 15:47:55 UTC, Adam D. Ruppe wrote:
On Sunday, 16 May 2021 at 15:12:25 UTC, Nick wrote:
Is this warning still valid?
The @property thing doesn't do much. All it does is change
typeof(a.prop) from function over to the return value of the
function. (Which act
On Sunday, 16 May 2021 at 15:12:25 UTC, Nick wrote:
Is this warning still valid?
The @property thing doesn't do much. All it does is change
typeof(a.prop) from function over to the return value of the
function. (Which actually makes it required for the range empty
and front things!)
The [Property
Functions](https://dlang.org/spec/function.html#property-functions) documentation reads:
WARNING: The definition and usefulness of property functions is
being reviewed, and the implementation is currently incomplete.
Using property functions is not recommended until the
On Wednesday, 12 May 2021 at 00:06:52 UTC, Paul Backus wrote:
On Tuesday, 11 May 2021 at 19:42:34 UTC, Chris Piker wrote:
std.traits.isOrderingComparable
https://phobos.dpldocs.info/std.traits.isOrderingComparable.html
Well I feel sheepish, don't know how I missed that one. Hey
thanks for p
On Tuesday, 11 May 2021 at 19:42:34 UTC, Chris Piker wrote:
My problem is that I don't know how to specify that properties
must be comparable via "<". I took a look at the Traits
module, but there are more things that are comparable then
Arithmetic or Floating point types. Also, since the com
Hi D
I'm working on a bit of code that handles selecting one *.front
from multiple range-ish objects. It's a select-or-drop algorithm
for a data streaming service, the details aren't important.
The algorithm takes a range of something I'll call
"PriorityRange" objects. PriorityRange object
On Tuesday, 11 May 2021 at 10:48:03 UTC, Mike Parker wrote:
On Tuesday, 11 May 2021 at 09:10:02 UTC, Vinod K Chandran wrote:
So in many situations, I need to check some boolean properties
of Window class and call some functions of Window class in
WndProc.
But I don't want to expose those props
On Tuesday, 11 May 2021 at 10:47:15 UTC, cc wrote:
The `package` protection attribute should work here if the
modules reside in the same package (directory)?
Thanks. "package" scope worked.
On Tuesday, 11 May 2021 at 09:10:02 UTC, Vinod K Chandran wrote:
So in many situations, I need to check some boolean properties
of Window class and call some functions of Window class in
WndProc.
But I don't want to expose those props and functions to the
user. So if I make them private, I can
On Tuesday, 11 May 2021 at 09:10:02 UTC, Vinod K Chandran wrote:
Hi all,
I am practising D with a win api GUI hobby project.
I have a Window class and it resides in module window.d
My WndProc function resides in another module named
wnd_proc_module.d
Inside my WndProc, I get the Window class li
11.05.2021 12:10, Vinod K Chandran пишет:
Hi all,
I am practising D with a win api GUI hobby project.
I have a Window class and it resides in module window.d
My WndProc function resides in another module named wnd_proc_module.d
Inside my WndProc, I get the Window class like this.
```d
Window win
Hi all,
I am practising D with a win api GUI hobby project.
I have a Window class and it resides in module window.d
My WndProc function resides in another module named
wnd_proc_module.d
Inside my WndProc, I get the Window class like this.
```d
Window win = cast(Window) (cast(void*) GetWindowLong
On Wednesday, 17 March 2021 at 19:38:48 UTC, Adam D. Ruppe wrote:
On Wednesday, 17 March 2021 at 19:32:02 UTC, uranuz wrote:
Seems that a problem with concatenation is because
Throwable.message has const(char)[] type, but not string. This
makes some inconvenience ;-)
Yes, that's what I though
On Wednesday, 17 March 2021 at 19:32:02 UTC, uranuz wrote:
Seems that a problem with concatenation is because
Throwable.message has const(char)[] type, but not string. This
makes some inconvenience ;-)
Yes, that's what I thought.
The concat operation tends to give the most flexible type of th
On Wednesday, 17 March 2021 at 17:52:20 UTC, Adam D. Ruppe wrote:
On Wednesday, 17 March 2021 at 17:46:27 UTC, uranuz wrote:
Also because it is not a property in some contexts when I try
to concatenate it with string without parentheses using "~"
operator it fails
Can you post s
On Wednesday, 17 March 2021 at 17:46:27 UTC, uranuz wrote:
Also because it is not a property in some contexts when I try
to concatenate it with string without parentheses using "~"
operator it fails
Can you post some sample code that demonstrates this?
The question is why Throwable.message is not a @property?! It
looks strange now, because "message" is not a *verb*, but a
*noun*. So it's expected to be a property. Also because it is not
a property in some contexts when I try to concatenate it with
string without pa
On Thu, Jun 11, 2020 at 10:46:32AM +, Paul Backus via Digitalmars-d-learn
wrote:
> On Thursday, 11 June 2020 at 05:41:25 UTC, H. S. Teoh wrote:
> >
> > Ironically, just today I ran into this corner case where @property
> > actually became a solut
On Thursday, 11 June 2020 at 05:41:25 UTC, H. S. Teoh wrote:
Ironically, just today I ran into this corner case where
@property actually became a solution to a real problem:
//-module1.d--
auto someGenericFunc(T)(T t) {
...
static if
On Wed, Jun 10, 2020 at 10:58:57PM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
> As things stand, @property has no real practical purpose but
> frequently gets used to indicate that it's the intention of a
> function's author for it to be used as if it
On Wednesday, June 10, 2020 3:41:54 PM MDT H. S. Teoh via Digitalmars-d-learn
wrote:
> On Wed, Jun 10, 2020 at 08:24:19PM +, Vinod K Chandran via Digitalmars-
d-learn wrote:
> > Hi all,
> > I read in an old thread that authors of D wants to eliminate
> > @property. I just
On Wednesday, 10 June 2020 at 23:03:21 UTC, Adam D. Ruppe wrote:
On Wednesday, 10 June 2020 at 22:50:17 UTC, Paul Backus wrote:
static assert(isInputRange!S); // passes
isInputRange doesn't check it but others do.
std.random.isSeedable requires @property on front for example.
Nope:
s
rs do.
std.random.isSeedable requires @property on front for example.
Nope:
struct S {
bool empty() { return false; }
int front() { return 0; }
void popFront() {}
enum bool isUniformRandom = true;
void seed(int s) {}
}
static assert(isSeedable!(S, int));
My bad, missed the one-arg
On Wednesday, 10 June 2020 at 22:50:17 UTC, Paul Backus wrote:
static assert(isInputRange!S); // passes
isInputRange doesn't check it but others do.
std.random.isSeedable requires @property on front for example.
Some apparently test incorrectly too, like
std.range.primitives.move
may have been true at one point, but it isn't true now:
>
> struct S {
> bool empty() { return false; }
> int front() { return 0; }
> void popFront() {}
> }
>
> static assert(isInputRange!S); // passes
Nice. So pretty soon I can get rid of @property spam
On Wednesday, 10 June 2020 at 22:30:37 UTC, Vinod K Chandran
wrote:
On Wednesday, 10 June 2020 at 22:15:25 UTC, 12345swordy wrote:
It can't do binary operations and unary operations.
@12345swordy, You mean we can't do such ops inside the property
?
No, it means you can'
On Wednesday, 10 June 2020 at 21:41:54 UTC, H. S. Teoh wrote:
There are a few places where it's needed (like satisfying the
range API, which implicitly checks for it)
That may have been true at one point, but it isn't true now:
struct S {
bool empty() { return false; }
int front() { re
On Wednesday, 10 June 2020 at 22:15:25 UTC, 12345swordy wrote:
It can't do binary operations and unary operations.
@12345swordy, You mean we can't do such ops inside the property ?
On Wednesday, 10 June 2020 at 21:40:44 UTC, Paul Backus wrote:
The current state of @property is that it doesn't really do
anything. D allows you to call functions without parentheses,
and to use assignment syntax to call a single-argument
function, so you can write getters and setters
On Wednesday, 10 June 2020 at 21:41:54 UTC, H. S. Teoh wrote:
It's stuck in limbo, like many things that people just cannot
agree on. There are a few places where it's needed (like
satisfying the range API, which implicitly checks for it), but
for the most part, you can just ignore it, it do
On Wednesday, 10 June 2020 at 21:40:44 UTC, Paul Backus wrote:
On Wednesday, 10 June 2020 at 20:24:19 UTC, Vinod K Chandran
wrote:
Hi all,
I read in an old thread that authors of D wants to eliminate
@property. I just roughly read the big thread bu couldn't find
a conclusion. After all
On Wednesday, 10 June 2020 at 20:24:19 UTC, Vinod K Chandran
wrote:
Hi all,
I read in an old thread that authors of D wants to eliminate
@property. I just roughly read the big thread bu couldn't find
a conclusion. After all that thread is a 48 page longer jumbo
thread. So out of curiosi
On Wed, Jun 10, 2020 at 08:24:19PM +, Vinod K Chandran via
Digitalmars-d-learn wrote:
> Hi all,
> I read in an old thread that authors of D wants to eliminate
> @property. I just roughly read the big thread bu couldn't find a
> conclusion. After all that thread is a 48
Hi all,
I read in an old thread that authors of D wants to eliminate
@property. I just roughly read the big thread bu couldn't find a
conclusion. After all that thread is a 48 page longer jumbo
thread. So out of curiosity, i am asking this. What is the
current state of @property ?
= { 10, 10, 10, 10 };
// ...content...
??? content
{
@property int x() const { return rect.left +
padding.left; }
}
}
int main()
{
auto b = new Base();
writeln( b.content.x );
}
How to implement "b.content.x" ( sequence call "content" of
?? content
{
@property int x() const { return rect.left +
padding.left; }
}
}
int main()
{
auto b = new Base();
writeln( b.content.x );
}
How to implement "b.content.x" ( sequence call "content" of the
"b" and then "x" of that ) ?
How to implement beauty ?
On Monday, 9 March 2020 at 19:10:54 UTC, Timon Gehr wrote:
https://wiki.dlang.org/DIP24
Hi , Timon Gehr
Thanks for the reply, very good DIPS.
I think this is very basic work, why the core team not take care
it for such a long time.
On 09.03.20 13:14, Adam D. Ruppe wrote:
Here's a wiki page referencing one of the 2013 discussions
https://wiki.dlang.org/Property_Discussion_Wrap-up
https://wiki.dlang.org/DIP24
On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote:
Here's a wiki page referencing one of the 2013 discussions
https://wiki.dlang.org/Property_Discussion_Wrap-up
though i'll note the thing is older than that.
What especially drove me nuts is people would so often say
On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote:
On Monday, 9 March 2020 at 10:09:56 UTC, Calvin P wrote:
@property exists so many years, Druntime & Phobos use it
2280 times. I can't believe it is not recommended.
They never implemented it right. This opCall type thin
On Monday, 9 March 2020 at 10:09:56 UTC, Calvin P wrote:
@property exists so many years, Druntime & Phobos use it
2280 times. I can't believe it is not recommended.
They never implemented it right. This opCall type thing was THE
case we brought up to introduce @property in the fi
On Monday, 9 March 2020 at 09:44:40 UTC, Simen Kjærås wrote:
As written on
https://dlang.org/spec/function.html#property-functions:
WARNING: The definition and usefulness of property functions
is being reviewed, and the implementation is currently
incomplete. Using property functions is not
On Monday, 9 March 2020 at 09:25:31 UTC, Calvin P wrote:
Is this a bugs ?
==
struct A {
ref auto opCall(string tmp) scope return {
return this;
}
}
struct B {
A _a;
@property ref auto a() scope return {
return _a
Is this a bugs ?
==
struct A {
ref auto opCall(string tmp) scope return {
return this;
}
}
struct B {
A _a;
@property ref auto a() scope return {
return _a;
}
}
extern(C) int main(){
A a;
a(&q
1 - 100 of 557 matches
Mail list logo
