Check out this article from Itzik Ben-Gan (and the function that he's created)... How to Compute Date and Time Difference in Parts

By "Windows Function", I'm assuming you mean "Windowed Function"... The kind with an OVER clause...
Windowing a function typically involves sorting data which tends to be one of the more...

What is the actual data type of your "date field"?

Given the context (the Kimball method of DW), the intention is that any time you actually need a date, you join to the dim_Date table and get the actual date...

Something like this...

DECLARE @DateAsInt INT = 20170625;

SELECT
    DateAsDate = DATEFROMPARTS(SUBSTRING(dc.DateAsChar, 1, 4), SUBSTRING(dc.DateAsChar, 5, 2), SUBSTRING(dc.DateAsChar, 7, 2))
FROM
    ( VALUES (CAST(@DateAsInt AS...

That's where I'm VERY VERY lucky... It was ordained from up on high, long ago, that applications may only call procs... No app generated, ad-hoc code allowed.
There "may" be...

See if something like the following will work for you.

Test data...

IF OBJECT_ID('tempdb..#TestData', 'U') IS NOT NULL
DROP TABLE #TestData;

CREATE TABLE #TestData...

Using an iTVF that produces a scalar value certainly works as a work around, at least in new development... The biggest problem is with existing code. It would be nice...

Here's a quick & dirty test to demonstrate the difference (and show that you can get similar performance w/o having to create an actual function).

declare @Products...