On Sunday, 14 April 2019 at 02:11:52 UTC, Mike Franklin wrote:
On Sunday, 14 April 2019 at 01:54:39 UTC, Jamie wrote:
Do @property attributes not allow postincrement operators?
...
It's a long standing issue (going on 7 years old)
...
I plan on getting to it, but there are other pressing
On Sunday, 14 April 2019 at 01:54:39 UTC, Jamie wrote:
Do @property attributes not allow postincrement operators?
import std.stdio;
struct Foo {
@property bar() { return 10; }
@property bar(int x) { writeln(x); }
}
void main()
{
Foo foo;
writeln(foo.bar); // actually calls
Do @property attributes not allow postincrement operators?
import std.stdio;
struct Foo {
@property bar() { return 10; }
@property bar(int x) { writeln(x); }
}
void main()
{
Foo foo;
writeln(foo.bar); // actually calls foo.bar();
foo.bar = 10; // calls foo.bar(10
t it seems that
I got the idea.
So even if I'd write opAssign or @property as a template
function, I won't be able to get their arguments at compile time
because every template takes different set of arguments: for
compile time and for run time.
And due to the fact that D is callin
On Friday, January 4, 2019 4:50:30 AM MST Jacob Shtokolov via Digitalmars-d-
learn wrote:
> On Friday, 4 January 2019 at 11:41:59 UTC, Simen Kjærås wrote:
> > The thing is, compile-time tests like static if and static
> > assert can only test values that are known at compile-time, and
> > are for
```
@property val(T v) {
static assert(v > 0);
value = v;
}
```
v is a run-time value, not available at compile time.
On Friday, 4 January 2019 at 11:45:24 UTC, Jacob Shtokolov wrote:
Here is the simple example:
https://run.dlang.io/gist/1a06dd703bea5548ee72b4713a7ce5f6
Sorry, invalid link.
Here is a new one: https://run.dlang.io/is/QZ5hLV
On Friday, 4 January 2019 at 11:41:59 UTC, Simen Kjærås wrote:
The thing is, compile-time tests like static if and static
assert can only test values that are known at compile-time, and
are for the most part useful only in templates.
Thanks for this answer! That's sad to hear.
But, is there
On Friday, 4 January 2019 at 11:45:24 UTC, Jacob Shtokolov wrote:
On Friday, 4 January 2019 at 10:34:07 UTC, Basile.B wrote:
Show us some code.
Here is the simple example:
https://run.dlang.io/gist/1a06dd703bea5548ee72b4713a7ce5f6
The thing I'm trying to do is to make an experimental port
On Friday, 4 January 2019 at 10:34:07 UTC, Basile.B wrote:
Show us some code.
Here is the simple example:
https://run.dlang.io/gist/1a06dd703bea5548ee72b4713a7ce5f6
The thing I'm trying to do is to make an experimental port (for
education purposes) of https://github.com/fthomas/refined
On Friday, 4 January 2019 at 09:54:25 UTC, Jacob Shtokolov wrote:
Hi,
I'd like to implement some compile time constraints for a
struct (though not sure if that's possible).
I already tried to place "static assert" or any kind of static
condition into a body of @property an
On Friday, 4 January 2019 at 09:54:25 UTC, Jacob Shtokolov wrote:
Hi,
I'd like to implement some compile time constraints for a
struct (though not sure if that's possible).
I already tried to place "static assert" or any kind of static
condition into a body of @property an
Hi,
I'd like to implement some compile time constraints for a struct
(though not sure if that's possible).
I already tried to place "static assert" or any kind of static
condition into a body of @property and opAssign(), but every time
it shows the error "variable cannot be
of the language) to make a
library implementation more appealing. IMO, it'd be great if we
could add more composable primitives to the language, and get rid
of quirky features like @property.
Mike
On Thursday, May 10, 2018 18:43:40 SrMordred via Digitalmars-d-learn wrote:
> struct T
> {
> int x;
> @property ref X(){ return x; }
> @property X(int v)
> {
> x = v;
> }
> }
>
> T t;
> t.X += 10;
>
> The setter 'x =
On 5/10/2018 3:18 PM, Ali Çehreli wrote:
On 05/10/2018 01:03 PM, Dlang User wrote:
>> this didn´t work either.
>> note that 'f.data+= 2;' don't call the write property
>
> That's odd, it works on my machine (Windows 10 with V2.079.0 DMD
compiler).
Try putting w
On 05/10/2018 01:03 PM, Dlang User wrote:
>> this didn´t work either.
>> note that 'f.data+= 2;' don't call the write property
>
> That's odd, it works on my machine (Windows 10 with V2.079.0 DMD
compiler).
Try putting writeln expressions in the two functions to see whic
On 5/10/2018 2:50 PM, SrMordred wrote:
On Thursday, 10 May 2018 at 19:41:41 UTC, Dlang User wrote:
On 5/10/2018 1:43 PM, SrMordred wrote:
[...]
I am relatively new to D and I was under the impression that that was
a limitation of @property functions.
But, re-reading the language reference
On Thursday, 10 May 2018 at 19:41:41 UTC, Dlang User wrote:
On 5/10/2018 1:43 PM, SrMordred wrote:
[...]
I am relatively new to D and I was under the impression that
that was a limitation of @property functions.
But, re-reading the language reference, it gave this example
(it returns
On 5/10/2018 1:43 PM, SrMordred wrote:
struct T
{
int x;
@property ref X(){ return x; }
@property X(int v)
{
x = v;
}
}
T t;
t.X += 10;
The setter 'x = v' are not executed because i´m returning the reference
of x.
And without the 'ref' the compiler complains
struct T
{
int x;
@property ref X(){ return x; }
@property X(int v)
{
x = v;
}
}
T t;
t.X += 10;
The setter 'x = v' are not executed because i´m returning the
reference of x.
And without the 'ref' the compiler complains because 'x' is not a
lvalue.
Any solution
On Tuesday, 24 April 2018 at 21:36:19 UTC, Rubn wrote:
I was wondering if I could create my own property in a way that
can be used the same way as something like "T.sizeof". Right
now I have the following to replace length:
uint length32(T)(T[] array)
{
return cast(uint)array.le
On Tuesday, April 24, 2018 21:36:19 Rubn via Digitalmars-d-learn wrote:
> I was wondering if I could create my own property in a way that
> can be used the same way as something like "T.sizeof". Right now
> I have the following to replace length:
>
> uint length32(T)(T[]
I was wondering if I could create my own property in a way that
can be used the same way as something like "T.sizeof". Right now
I have the following to replace length:
uint length32(T)(T[] array)
{
return cast(uint)array.length;
}
I want something similar to be able to do the
löw wrote:
>> Should ranges always provide a length property?
>
> No.
>
>> If so, in which cases is a length property an advantage or >> a
requirement?
>
> Just provide it whenever it is cheap to do so. If you need > to do
complex calculations or especi
On Tue, Apr 10, 2018 at 10:07:40PM +, Cym13 via Digitalmars-d-learn wrote:
[...]
> On the other hand I don't think the end user should have to scratch
> his head to find the length of a range, especially if it's not trivial
> to get (say, O(log n) kind of case). Therefore exposing a method in
34:40 UTC, Adam D. Ruppe wrote:
> >> > On Tuesday, 10 April 2018 at 14:25:52 UTC, Nordlöw wrote:
> >> >> Should ranges always provide a length property?
> >> >
> >> > No.
> >> >
> >> >> If so, in which cases is a length
es always provide a length property?
>
> No.
>
>> If so, in which cases is a length property an advantage or
>> a requirement?
>
> Just provide it whenever it is cheap to do so. If you need
> to do complex calculations or especially loop over contents
>
On Tuesday, 10 April 2018 at 20:16:18 UTC, Steven Schveighoffer
wrote:
e.g. std.array.array is going to pre-allocate an array of the
correct length and fill it in, vs. appending each element as it
gets them from the range.
Personally, I would store the length because typically a
container
On 4/10/18 4:08 PM, Jonathan M Davis wrote:
On Tuesday, April 10, 2018 19:47:10 Nordlöw via Digitalmars-d-learn wrote:
I'm thinking of my own container Hashmap having its range
ByKeyValue requiring one extra word of memory to store the
iteration count which, in turn, can be used to calculate
On Tuesday, April 10, 2018 19:47:10 Nordlöw via Digitalmars-d-learn wrote:
> On Tuesday, 10 April 2018 at 14:34:40 UTC, Adam D. Ruppe wrote:
> > On Tuesday, 10 April 2018 at 14:25:52 UTC, Nordlöw wrote:
> >> Should ranges always provide a length property?
> >
> > No.
On Tuesday, 10 April 2018 at 14:34:40 UTC, Adam D. Ruppe wrote:
On Tuesday, 10 April 2018 at 14:25:52 UTC, Nordlöw wrote:
Should ranges always provide a length property?
No.
If so, in which cases is a length property an advantage or a
requirement?
Just provide it whenever it is cheap
On Tuesday, April 10, 2018 14:25:52 Nordlöw via Digitalmars-d-learn wrote:
> Should ranges always provide a length property?
>
> If so, in which cases is a length property an advantage or a
> requirement?
Whether a range has a length property or not is primarily dependent on h
On Tuesday, 10 April 2018 at 14:25:52 UTC, Nordlöw wrote:
Should ranges always provide a length property?
No.
If so, in which cases is a length property an advantage or a
requirement?
Just provide it whenever it is cheap to do so. If you need to do
complex calculations or especially loop
Should ranges always provide a length property?
If so, in which cases is a length property an advantage or a
requirement?
that
part.
Do you think I should I omit the @property tag, if the only
wanted behaviour is to set a value (`foo.bar = "baz";`) ?
Yes I would omit @proporty if you don't need it as it isn't
really useful at the moment.
There's a DIP to fix it and make it more powerful thou
On Monday, 2 April 2018 at 15:15:05 UTC, Dennis wrote:
On Monday, 2 April 2018 at 14:51:57 UTC, Vladimirs Nordholm
wrote:
Do you think I should I omit the @property tag, if the only
wanted behaviour is to set a value (`foo.bar = "baz";`) ?
You're probably fine either way, i
On Monday, 2 April 2018 at 14:51:57 UTC, Vladimirs Nordholm wrote:
Do you think I should I omit the @property tag, if the only
wanted behaviour is to set a value (`foo.bar = "baz";`) ?
You're probably fine either way, it's mostly for making your
intention clear. Jonathan M Davis ma
On Monday, 2 April 2018 at 14:51:57 UTC, Vladimirs Nordholm wrote:
On Monday, 2 April 2018 at 14:20:49 UTC, Dennis wrote:
On Monday, 2 April 2018 at 13:57:14 UTC, Vladimirs Nordholm
wrote:
Is there any reason for me to add the @property tags for the
method?
A list of things the @property tag
On Monday, 2 April 2018 at 14:20:49 UTC, Dennis wrote:
On Monday, 2 April 2018 at 13:57:14 UTC, Vladimirs Nordholm
wrote:
Is there any reason for me to add the @property tags for the
method?
A list of things the @property tag does can be found here:
https://dlang.org/spec/function.html
On Monday, 2 April 2018 at 13:57:14 UTC, Vladimirs Nordholm wrote:
Is there any reason for me to add the @property tags for the
method?
A list of things the @property tag does can be found here:
https://dlang.org/spec/function.html#property-functions
This behavior is particularly useful
Heyo.
I have a struct with a couple "property" methods, like:
struct A
{
auto foo(int bar) { /* do something */ }
}
Is there any reason for me to add the @property tags for the
method? The following code compiles just fine with the struct
above
A a = A();
On Monday, 12 March 2018 at 13:04:54 UTC, Simen Kjærås wrote:
On Monday, 12 March 2018 at 10:37:00 UTC, Alex wrote:
Sure, you have.
https://dlang.org/spec/struct.html#assign-overload
Point #4.
In this case,
ref S opAssign(ref S rhs)
{
return this;
}
True. Can you fix these, too?
struct
On Monday, 12 March 2018 at 10:37:00 UTC, Alex wrote:
Sure, you have.
https://dlang.org/spec/struct.html#assign-overload
Point #4.
In this case,
ref S opAssign(ref S rhs)
{
return this;
}
True. Can you fix these, too?
struct S {
S* ptr;
this(int dummy) {
ptr =
}
On Monday, 12 March 2018 at 09:54:20 UTC, Simen Kjærås wrote:
But I don't have a hook to update the pointer when the struct
is moved. The GC may move my struct without informing me in any
way. In fact, even just a copy construction will break this:
struct S {
S* ptr;
this(int dummy)
On Monday, 12 March 2018 at 08:59:49 UTC, Alex wrote:
An incomplete type is perfectly ok, so there should be no
problem with a pointer of the same type inside a struct.
If accidentally the pointer refers "this", then it must have
been set after construction. As before construction the value
of
On Monday, 12 March 2018 at 07:04:19 UTC, Simen Kjærås wrote:
On Saturday, 10 March 2018 at 17:43:06 UTC, Simen Kjærås wrote:
I'm not sure how fixable this is, but I am sure that there's
plenty of benefit to being able to write code like this:
struct S {
int n, m;
SomeType!(() => n +
On Saturday, 10 March 2018 at 17:43:06 UTC, Simen Kjærås wrote:
I'm not sure how fixable this is, but I am sure that there's
plenty of benefit to being able to write code like this:
struct S {
int n, m;
SomeType!(() => n + m) a;
}
over this:
struct S {
int n, m;
auto a() {
On Friday, 9 March 2018 at 23:34:56 UTC, Mike Franklin wrote:
On Friday, 9 March 2018 at 14:46:04 UTC, Simen Kjærås wrote:
1) Wrong return type:
unittest {
S s;
auto a = s.field;
// Fails - typeof(a) is Property!((get) => this.n, (set)
=> this.n = set)
assert(is(
On Friday, 9 March 2018 at 14:46:04 UTC, Simen Kjærås wrote:
This is the best I've come up with in the current language:
struct S {
int n;
mixin property!("field", "get => this.n", "set => this.n =
set");
}
Not bad. Not good, but not bad either.
be scalable to data that isn't addressable (e.g.
bitfields). See
https://issues.dlang.org/show_bug.cgi?id=16187
This is the best I've come up with in the current language:
struct S {
int n;
mixin property!("field", "get => this.n", "set => this.n =
set")
On Friday, 9 March 2018 at 01:22:15 UTC, Mike Franklin wrote:
I would like to know if this can be improved to support the
following:
* binary assignment operators (e.g. +=)
* unary assignment operators (e.g. ++)
* @safe, @nogc, and -betterC compatible
* at least as good code generation as
On Tuesday, 20 February 2018 at 14:34:53 UTC, bauss wrote:
Would there be a reason why this wouldn't be a good
implementation?
If so what and how could it be improved?
Are there flaws in an implementation like this?
[... snip ...]
I am very interested in this as a potential alternative to
ght of many more corner cases than
you have. There is an argument to be made for compile-time
overhead, I guess.
So, my version of the same:
struct Property(T, bool readOnly = false)
{
private T _value;
static if (readOnly)
T __GET() { return _value; }
else
Would there be a reason why this wouldn't be a good
implementation?
If so what and how could it be improved?
Are there flaws in an implementation like this?
struct Property(T, bool readOnly = false)
{
import std.traits : isScalarType, isArray,
isAssociativeArray, isSomeString
identifiers poses an extra challenge.
I may go for string mixin's instead, which I just discovered do
work:
```
import std.stdio;
enum getter = `
@property int p()
{
writeln(__LINE__, " mixin getter");
return 3;
}
`;
string setter(string T) pur
On 01/24/2018 02:24 PM, Bastiaan Veelo wrote:
`Alias this` to mixed in properties does not seem to work, see below. If
you think it should, I'll file an issue. Otherwise: can this be made to
work somehow?
Not supposed to work as it is. The spec says that you cannot make an
overload set just
`, then the
remaining property works. Does the compiler detect identical
names and then does some additional mangling which messes with my
`alias this` maybe?
```
import std.stdio;
// version = manual; // Manually written property works,
obviously.
mixin template getter()
{
@property int p
On Wednesday, 3 January 2018 at 08:51:55 UTC, Simen Kjærås wrote:
On Saturday, 30 December 2017 at 03:49:37 UTC, ChangLong wrote:
What I am try to do is implement a unique data type. (the
ownership auto moved into new handle)
Have you considered std.typecons.Unique[0]? If yes, in what
ways
On Saturday, 30 December 2017 at 03:49:37 UTC, ChangLong wrote:
What I am try to do is implement a unique data type. (the
ownership auto moved into new handle)
Have you considered std.typecons.Unique[0]? If yes, in what ways
does it not cover your needs?
Your example code written with
On 12/29/2017 07:49 PM, ChangLong wrote:
On Wednesday, 20 December 2017 at 18:43:21 UTC, Ali Çehreli wrote:
Thanks to Mengü for linking to that section. I have to make
corrections below.
Ali
Thanks for explain, Ali And Mengu.
What I am try to do is implement a unique data type. (the
On Wednesday, 20 December 2017 at 18:43:21 UTC, Ali Çehreli wrote:
Thanks to Mengü for linking to that section. I have to make
corrections below.
Ali
Thanks for explain, Ali And Mengu.
What I am try to do is implement a unique data type. (the
ownership auto moved into new handle)
Thanks to Mengü for linking to that section. I have to make corrections
below.
On 12/20/2017 10:04 AM, Ali Çehreli wrote:
> 'auto ref' essentially generates two copies of the function: one taking
> by-value for rvalues
Note that by-value for rvalues means "blitting" in D (blit: bit-level
On Wednesday, 20 December 2017 at 18:04:57 UTC, Ali Çehreli wrote:
On 12/20/2017 07:02 AM, ChangLong wrote:
> [...]
is not
> [...]
The problem is not with opAssign but with left(), which returns
an rvalue. It's by design that rvalues cannot be bound to
references in D.
[...]
was just
On 12/20/2017 07:02 AM, ChangLong wrote:
> ===
> struct A {
> alias This= typeof(this) ;
>
> void opAssign(ref This ){
> }
>
> ref auto left(){
> return This() ;
> }
> }
>
> void main(){
> Aroot ;
> ref find() {
>
===
struct A {
alias This = typeof(this) ;
void opAssign(ref This ){
}
ref auto left(){
return This() ;
}
}
void main(){
A root ;
On Thursday, 9 November 2017 at 14:34:10 UTC, Steven
Schveighoffer wrote:
On 11/9/17 7:34 AM, Timoses wrote:
I suppose this is what Adam suggested, correct?
Yes, more or less. It's just an actual implementation vs. a
description in case it wasn't clear.
[...]
It's not much different
On 11/9/17 7:34 AM, Timoses wrote:
I suppose this is what Adam suggested, correct?
Yes, more or less. It's just an actual implementation vs. a description
in case it wasn't clear.
This is a more general question: Why is it not possible to
implement/override static methods?
Static
On Wednesday, 8 November 2017 at 18:33:15 UTC, Steven
Schveighoffer wrote:
On 11/8/17 12:38 PM, Timoses wrote:
Hey,
wrapping my head around this atm..
[snip]
so what you want is a static variable per subclass, but that
the base class can access.
What I would recommend is this:
abstract
On Wednesday, 8 November 2017 at 17:46:42 UTC, Adam D. Ruppe
wrote:
On Wednesday, 8 November 2017 at 17:38:27 UTC, Timoses wrote:
Are there better options/ways of achieving this?
What are you actually trying to achieve? What are you using
these variables for?
Well, I have the following
On 11/8/17 12:38 PM, Timoses wrote:
Hey,
wrapping my head around this atm..
[snip]
so what you want is a static variable per subclass, but that the base
class can access.
What I would recommend is this:
abstract class Base
{
int x();
}
class A : Base
{
private static int _x = 1;
On Wednesday, 8 November 2017 at 17:38:27 UTC, Timoses wrote:
Are there better options/ways of achieving this?
What are you actually trying to achieve? What are you using these
variables for?
My first thought is you should abandon the variable approach and
just use an abstract function
On Wednesday, 8 November 2017 at 17:38:27 UTC, Timoses wrote:
Option 2:
class Base { int x;}
class A : Base
{
this() { x = 1; }
}
class B : Base
{
this() { x = 2; }
}
Con: Well, the downside is that every instance of A and B
allocates space for x although only one allocation would be
Hey,
wrapping my head around this atm..
How would I achieve that children statically set a property of
the parent so that the property is distinct between different
children?
The following is *bs*, but kind of illustrates what I'd "like":
class Base
{
int x;
}
clas
On Sunday, 1 October 2017 at 07:11:14 UTC, bitwise wrote:
On Sunday, 1 October 2017 at 05:57:53 UTC, Tony wrote:
"@property functions can only have zero, one or two parameters"
I am looking for an example of an @property function defined
with two parameters and the synt
On Sunday, 1 October 2017 at 06:34:56 UTC, Jonathan M Davis wrote:
On Sunday, October 01, 2017 05:57:53 Tony via
Digitalmars-d-learn wrote:
"@property functions can only have zero, one or two parameters"
I am looking for an example of an @property function defined
with two
On Sunday, 1 October 2017 at 05:57:53 UTC, Tony wrote:
"@property functions can only have zero, one or two parameters"
I am looking for an example of an @property function defined
with two parameters and the syntax for how it is accessed
without ().
And also this, which probably
On Sunday, October 01, 2017 05:57:53 Tony via Digitalmars-d-learn wrote:
> "@property functions can only have zero, one or two parameters"
>
> I am looking for an example of an @property function defined with
> two parameters and the syntax for how it is accessed with
"@property functions can only have zero, one or two parameters"
I am looking for an example of an @property function defined with
two parameters and the syntax for how it is accessed without ().
On Saturday, 30 September 2017 at 08:20:44 UTC, Nicholas Wilson
wrote:
struct MyType
{
void* ptr;
static struct Info
{
@(42) int foo;
}
// Should be generated by the mixin below
@property int foo()
{
int ret;
getMyTypeInfo(ptr,42,int.sizeof
struct MyType
{
void* ptr;
static struct Info
{
@(42) int foo;
}
// Should be generated by the mixin below
@property int foo()
{
int ret;
getMyTypeInfo(ptr,42,int.sizeof,);
return ret;
}
mixin generateInfo!getMyTypeInfo
On Saturday, 5 August 2017 at 15:19:43 UTC, Gerald wrote:
On Saturday, 5 August 2017 at 15:08:21 UTC, Johnson Jones wrote:
I am trying to get the handle size of panned. Not sure if I'm
doing it right but
[...]
I'm using this in Tilix:
Value handleSize = new Value(0);
On Saturday, 5 August 2017 at 15:08:21 UTC, Johnson Jones wrote:
I am trying to get the handle size of panned. Not sure if I'm
doing it right but
[...]
I'm using this in Tilix:
Value handleSize = new Value(0);
paned.styleGetProperty("handle-size", handleSize);
ct-WARNING **: g_object_get_property: object class
'GtkStyle' has no property named 'handle-size'
if I do
mainPaned.getStyle().getProperty("handle-size", value);
I haven't been able to figure out how to get it.
I've also tried
mainPaned.getStyle().getStyleProperty(...
but the first parame
On Wednesday, 26 July 2017 at 16:27:57 UTC, WhatMeWorry wrote:
On Wednesday, 26 July 2017 at 02:31:33 UTC, Mike Parker wrote:
With static arrays, the memory for the elements if part of the
array itself, so it is counted in the size. For dynamic
arrays, it is not. For .sizeof to report the
On Wednesday, 26 July 2017 at 02:32:07 UTC, Adam D. Ruppe wrote:
I've hand rolled a function which is working for me currently,
but with my coding ability, I'd feel much safer with something
official :)
You could also do (cast(ubyte[]) array).length.
This was my (way over complicated)
On Wednesday, 26 July 2017 at 02:31:33 UTC, Mike Parker wrote:
On Wednesday, 26 July 2017 at 02:24:06 UTC, WhatMeForget wrote:
[...]
Because .sizeof has nothing to do with how many elements are in
the array. It tells you how much space the array itself takes
up.
Totally agree. .length
On Wednesday, 26 July 2017 at 02:24:06 UTC, WhatMeForget wrote:
Static Arrays have property
.sizeof which returns the array length multiplied by the number
of bytes per array element.
Dynamic Arrays have property
.sizeof which returns the size of the dynamic array reference,
which is 8 in 32
On Wednesday, 26 July 2017 at 02:24:06 UTC, WhatMeForget wrote:
Static Arrays have property
.sizeof which returns the array length multiplied by the number
of bytes per array element.
Dynamic Arrays have property
.sizeof which returns the size of the dynamic array reference,
which is 8 in 32
Static Arrays have property
.sizeof which returns the array length multiplied by the number
of bytes per array element.
Dynamic Arrays have property
.sizeof which returns the size of the dynamic array reference,
which is 8 in 32-bit builds and 16 on 64-bit builds.
Why not have dynamic
Thanks for reply, Ali.
On 07/15/2017 12:53 PM, closescreen wrote:
Let i have code:
Clock.currTime.to!DateTime.Interval!DateTime( 24.hours ).fwdRange(
h=>h+1.hours ).writeln;
Now if i want to set the minute=0 and second=0 without breaking chain,
what i should do?
I think about somewhat like:
with(
I found this solution:
Clock.currTime.to!DateTime.pipe!( dt=>(dt.minute=0,dt.second=0,
dt) ).Interval!DateTime( 24.hours ).fwdRange( h=>h+1.hours
).writeln;
Or:
Clock.currTime.to!DateTime.pipe!( "a.minute=0, a.second=0, a"
).Interval!DateTime( 24.hours ).fwdRange( h=>h+1.hours ).writeln;
Let i have code:
Clock.currTime.to!DateTime.Interval!DateTime( 24.hours
).fwdRange( h=>h+1.hours ).writeln;
Now if i want to set the minute=0 and second=0 without breaking
chain, what i should do?
I think about somewhat like:
with( Clock.currTime.to!DateTime){
minute=0;
second=0
On Thursday, 11 May 2017 at 08:42:26 UTC, Nicholas Wilson wrote:
Are you in windows perchance? IIRC the when compiling for 32
bit it doesn't use the 64 bit C file function so that will not
work.
Yes, windows. Ok, I understood you.
On Thursday, 11 May 2017 at 07:24:00 UTC, AntonSotov wrote:
import std.stdio;
int main()
{
auto big = File("bigfile", "r+"); //bigfile size 20 GB
writeln(big.size); // ERROR!
return 0;
}
//
std.exception.ErrnoException@std\stdio.d(1029): Could
On Thursday, 11 May 2017 at 07:24:00 UTC, AntonSotov wrote:
import std.stdio;
int main()
{
auto big = File("bigfile", "r+"); //bigfile size 20 GB
writeln(big.size); // ERROR!
return 0;
}
//
std.exception.ErrnoException@std\stdio.d(1029): Could
import std.stdio;
int main()
{
auto big = File("bigfile", "r+"); //bigfile size 20 GB
writeln(big.size); // ERROR!
return 0;
}
//
std.exception.ErrnoException@std\stdio.d(1029): Could not seek in
file `bigfile` (Invalid argument)
I can not
On Wednesday, 10 May 2017 at 16:40:09 UTC, Aldo wrote:
class PictureBox : Control
{
@property
public override void texture(Texture value)
{
writeln("override");
this.m_texture = value;
}
}
Error: function f340.PictureB
Hello,
can you tell me if this compilation error is normal ?
class Texture
{
public this()
{
}
}
class Control
{
private Texture m_texture;
@property
{
public Texture texture
101 - 200 of 536 matches
Mail list logo
