Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can not use nim 2's new default instantiation with any object type with a DateTime field #20681

Closed
PhilippMDoerner opened this issue Oct 27, 2022 · 3 comments · Fixed by #20639
Assignees

Comments

@PhilippMDoerner
Copy link
Contributor

What happened?

It is currently impossible to instantiate a DateTime object at compile time. That makes it impossible to make use of nim 2's new feature of default instantiation for any object with fields of the DateTime type.

These are the ways I tried so far:

Attempt 1:

import std/times

type A = object
  d: DateTime = DateTime()

let x = default(A)

Attempt 2:

import std/times

type A = object
  d: DateTime = dateTime(2020, 1.Month, 1)

let x = default(A)

Attempt 3:

import std/times

type A = object
  d: DateTime = now()

let x = default(A)

Nim Version

Nim Compiler Version 1.7.3 [Linux: amd64]
Compiled at 2022-10-23
Copyright (c) 2006-2022 by Andreas Rumpf

git hash: fa1606c
active boot switches: -d:release

Current Standard Output Logs

Attempt 1:
Error: the field 'nanosecond' is not accessible.


Attempt 2:
/.choosenim/toolchains/nim-#devel/lib/pure/times.nim(1366, 6) Error: cannot evaluate at compile time: localInstance


Attempt 3:
/.choosenim/toolchains/nim-#devel/lib/pure/times.nim(971, 13) Error: cannot 'importc' variable at compile time; clock_gettime

Expected Standard Output Logs

No Error message as above

Possible Solution

Suggestions:

  1. Provide a separate proc that can solely be used to instantiate some dummy value for DateTime at compileTime.
  2. Make the fields of DateTime public so that one can use DateTime() to instantiate a DateTime themselves with dummy values

Additional Information

I believe this to be pretty relevant in particular for the feature provided by #20480 , as types with DateTimes aren't all that rare. Unless such a feature can be provided I effectively am unable to make use of it, as I must use ElegantBeef's constructor package for all types with DateTime fields and when I have that dependency anyway I might as well use it in general.

@PhilippMDoerner PhilippMDoerner changed the title Can not use default instantiation with any object with a DateTime field Can not use nim 2's new default instantiation with any object type with a DateTime field Oct 27, 2022
@PhilippMDoerner
Copy link
Contributor Author

PhilippMDoerner commented Oct 27, 2022

For reference, ultimately I want to be able to default instantiate objects with a type that is a distinct version of DateTime, something like this:

# What I'd like to work
import std/times

type DjangoDateTime = distinct DateTime

type Default = object
  data: DjangoDateTime = DateTime().DjangoDateTime

let x = default(Default)
echo x.repr

Ringabout granted me an example that should work for now with fields that have pure DateTime types:

# Works - workaround for objects with pure DateTime fields
import std/times

import std/importutils

privateAccess DateTime

type
  Default = object
    data: DateTime = Datetime(second: 10)

let x = default(Default)
echo x.data.second

Sadly it is impossible to make use of this for default instantiation

# Doesn't work, attempted workaround for distinct Datetime Fields
import std/times

import std/importutils

type DjangoDateTime = distinct DateTime

privateAccess DateTime
privateAccess DjangoDateTime

type Default = object
  data: DjangoDateTime = DateTime().DjangoDateTime

let x = default(Default)
echo x.repr

Errors out with:

 Error: type mismatch: got 'DateTime' for 'DateTime(nanosecond: 0, second: 0, minute: 0, hour: 0, monthdayZero: 0,
         monthZero: 0, year: 0, weekday: dMon, yearday: 0, isDst: false,
         timezone: nil, utcOffset: 0)' but expected 'DjangoDateTime = distinct DateTime'

@ringabout
Copy link
Member

ringabout commented Oct 27, 2022

Likewise for the second example

import std/times

import std/importutils

type DjangoDateTime = distinct DateTime

privateAccess DateTime
privateAccess DjangoDateTime
import std/macros
block:
  macro foo(x: static DjangoDateTime) =
    discard x

  macro foo2: untyped =
    var x: DjangoDateTime = DjangoDateTime(DateTime())

    result = quote do:
      foo(`x`)

  foo2()

outputs

macro foo(x: static DjangoDateTime)
  first type mismatch at position: 1
  required type for x: static[DjangoDateTime]
  but expression '(nanosecond: 0, second: 0, minute: 0, hour: 0, monthdayZero: 0, monthZero: 0,
 year: 0, weekday: dMon, yearday: 0, isDst: false, timezone: nil, utcOffset: 0)' is of type: DateTime

expression: foo((nanosecond: 0, second: 0, minute: 0, hour: 0, monthdayZero: 0,
     monthZero: 0, year: 0, weekday: dMon, yearday: 0, isDst: false,
     timezone: nil, utcOffset: 0))

@ringabout
Copy link
Member

ringabout commented Oct 28, 2022

The first case has been covered by #20639

The second and third case shouldn't work according to the RFC. The default field shouldn't have side effects. And the procs called should work at compile time.

The fourth case seems to be pre-existing as the example I have shown.

ringabout added a commit that referenced this issue Oct 28, 2022
Varriount pushed a commit that referenced this issue Oct 28, 2022
* don't sem const objectConstr defaults

* fixes

* add `efSkipFieldVisibilityCheck`; fixes nkBracket types

* fixes #20681

* fixes tests

* suggestion from @metagn

* fixes tests

Co-authored-by: xflywind <[email protected]>
capocasa pushed a commit to capocasa/Nim that referenced this issue Mar 31, 2023
…im-lang#20639)

* don't sem const objectConstr defaults

* fixes

* add `efSkipFieldVisibilityCheck`; fixes nkBracket types

* fixes nim-lang#20681

* fixes tests

* suggestion from @metagn

* fixes tests

Co-authored-by: xflywind <[email protected]>
bung87 pushed a commit to bung87/Nim that referenced this issue Jul 29, 2023
…im-lang#20639)

* don't sem const objectConstr defaults

* fixes

* add `efSkipFieldVisibilityCheck`; fixes nkBracket types

* fixes nim-lang#20681

* fixes tests

* suggestion from @metagn

* fixes tests

Co-authored-by: xflywind <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants